> 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 <fe...@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 -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
