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

Ansgar Burchardt ansgar.burchardt at iwr.uni-heidelberg.de
Fri Jan 13 12:28:40 CET 2012


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




More information about the Dune mailing list