Trilinos packages

[Nico Schlömer]

> yes. the old trilinos debian source package had a libname.patch and a
> soname.patch, these fix the names for a monolithic package. i suggest to
> import these (or just rebase your work on top of that).

I already incorporated a fix for proper so-naming upstream a while
ago, so that should be fixed.

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

  * 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.

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.


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

Really? Why?

> is there a specific
> reason to maintain a second and different repository for ubuntu?

Not particularly. I just have Trilinos built on a nightly basis on
launchpad to make sure upcoming changes won't bite us; it also serves
me well as a test bed for changes in debian/.

Cheers,
Nico



On Wed, Mar 26, 2014 at 5:03 PM, Felix Salfelder <felix at salfelder.org> wrote:
> On Wed, Mar 26, 2014 at 10:22:23AM +0100, Nico Schlömer wrote:
>> I would suggest to first go with a monolithic
>> package and split it up at a later point.
>
> yes. the old trilinos debian source package had a libname.patch and a
> soname.patch, these fix the names for a monolithic package. i suggest to
> import these (or just rebase your work on top of that).
>
> also, theres a note on renaming in README.Debian. and a changelog that
> would be nice to have.
>
> README.Debian
> [..]
> Debian Trilinos libraries renaming
> ==================================
>
> Following a discussion with ftpmaster, the Trilinos libraries have
> been renamed to be less generic. They all use the same prefix now :
> libtrilinos_ . That should also help tremendously with
>  - avoiding conflicts with other libraries/packages
>  - identifying available trilinos libraries
> [..]
>
>> In the course of packaging Trilinos for Debian, I have identified
>> quite a number of bugs in Trilinos for which I maintain a little zoo
>> of patches, https://github.com/nschloe/trilinos-ubuntu/tree/master/patches.
>> Some of those have already made it upstream, and we'll have to see if
>> we can get in more of those before the next release freeze.
>
> ideally those patches should be included in your package at alioth
> (whether or not they have been accepted upstream). is there a specific
> reason to maintain a second and different repository for ubuntu?
>
> regards
> felix