Trilinos packages

[Felix Salfelder]

On Thu, Mar 27, 2014 at 10:58:02PM +0100, Nico Schlömer wrote:
> As for the prefixing of the libraries with "trilinos_", I'd rather
> refrain from it for the moment. The arguments I can see for this

i see. perhaps it would be helpful to dig out the the referenced
'discussion with the ftpmaster' for the exact reasoning. anyway the
debian-policy [1] just states that

"""
If you have several shared libraries built from the same source tree,
you may lump them all together into a single shared library package
provided that all of their SONAMEs will always change together. Be aware
that this is not normally the case, and if the SONAMEs do not change
together, upgrading such a merged shared library package will be
unnecessarily difficult because of file conflicts with the old version
of the package. When in doubt, always split shared library packages so
that each binary package installs a single shared library.
""".

>   * The Debian package for Trilinos is meant for a researcher to get
> an application to compile and run with Trilinos to then deploy it on
> an HPC. If Debian follows a non-default library naming scheme, the
> user would have to maintain two separate build files for Debian and
> the cluster (which will typically host a customized Trilinos
> installation).
> 
>    * The new Trilinos package includes many more subpackages than the
> old one did. Maintaining a Debian patch that changes all library names
> is possible, but would be a substantial effort.
> 
>    * The old README brings up that prefixing avoids conflicts. While
> it it remains possible that another library by the same name appears
> in Debian, that has not been the case as long as Trilinos in Debian
> existed and isn't the case now.
> 
>    * The old README brings up that it would be easier to identify
> trilinos libraries. While that is true, a user of Trilinos typically
> has a very good idea of what libraries he or she plans to use.
> 

i tend to agree. but lets have a look at the proposed "split library
packages" variant... the control file will will blow up, but only once.
the next hurdle will be installing the files into the right packages. it
should be rather possible to do this half-way automatically...

i'm starting to like the idea of splitting up the package. it will cause
a lot of packages, but no extra headaches.

> That said, I do see the benefit of prefixing the libraries with
> "trilinos_". I would suggest that I file a bug report upstream, talk
> to some of the developers, and see if we can incorporate that change
> in Trilinos itself. We would probably have to wait for a major
> release, but I think this coming fall they are bumping the major
> release number.

from the perspective of a trilinos developer, all library packages are
packages on their own, and the naming scheme looks fine to me. just
because we (may) want to lump them together into one binary package
doesnt justify a change, imo.

> > ideally those patches should be included in your package at alioth
> > (whether or not they have been accepted upstream).
> 
> Really? Why?

i was assuming that the patches make sense. some of them apparently are
build system related. so why not?

hth, regards
felix