[Dune] Debian packages -- what is the status?

[Ansgar Burchardt]

On 01/11/2012 04:09 PM, Oliver Sander wrote:
>> There are several things still on my TODO list for the packages:
>>
>> - How to handle sonames for the shared libraries? They need to change
>> on each ABI change which likely means every DUNE release. I am not
>> sure if it also depends on the selected configure options.
>>
> I'd be surprised if there wasn't some configure flag that changes
> the ABI. We never cared about these things, but Dune starts being
> mature (and widely used) enough that we may want to start caring.

For now I build packages with a soname of the form

   libdunecommon-$(VERSION).so
   for example: libdunecommon-2.2svn.so

It at least changes with every release. (I can provide the patch for this.)

If the ABI also depends on the configure options, it might be better to 
use a Debian-specific name instead.

>> - Which options should be used to build binary packages? This also
>> involves checking the licenses of the used external libraries.
>> Currently I used --enable-parallel, --enable-shared,
>> --enable-fieldvector-size-is-method, --with-alberta, --with-gmp and
>> --with-superlu.
>
> That's more difficult, because there is not one true answer. I for example
> never use/need --enable-parallel. Stuff like --with-alberta is no
> problem on the other hand, because alberta is available from the
> official Debian archives.

The packages should be usable for most people, so I believe it would be 
best to enable most options (as far as this is possible).  For options 
like alberta that only add additional parts this should be safe, however 
I am not sure about --enable-parallel.  Will programs that do not use 
MPI still work correctly when linked against DUNE libraries that are 
built with MPI support?

>> - Maybe debug symbols should be included in -dbg packages? Should be
>> easy to implement.
>
> That would definitely be nice. Do we want -doc packages, too?

I did add the debug packages today.  Packages with the documentation are 
already generated.

 >> - debian/copyright needs a list of copyright holders if the package
 >> should be included in the official Debian archive later.
 >
 > Such a list wouldn't hurt anyways, even without Debian.

Any idea who to ask about this?

 > Actually I think he is right in aiming for official Debian inclusion.
 > Legal issues aside I don't see any reason not to maintain official
 > Debian packages other than being scared of the responsibility (that's
 > what's been keeping me from doing it).

If you are interested in looking after the Debian packages, you can 
co-maintain them.  Having someone more knowledgeable about DUNE should 
not hurt.

 > Yes, I have also come to the conclusion that the best way of dealing
 > with the UG licensing problems is to split UGGrid into a separate
 > module.
 >
 > For a while I thought about the possibility of creating several
 > different binary Debian packages from a single source package. That
 > way you could have dune-grid-without-uggrid.deb and
 > dune-grid-with-uggrid.deb, both built from the same sourcepackage.
 > However,
 > - I never found documentation on how to actually do that
 > - The number of different binary packages could grow rather quickly

This is not so simple so I would like to avoid this.  Also one would 
have to disable the UGGrid package for any package that is distributed 
to third parties.

Regards,
Ansgar