Hi, On 07/09/2015 06:39 PM, Bas Wijnen wrote: > On Thu, Jul 09, 2015 at 05:26:32PM +0200, Ansgar Burchardt wrote: >> I'm wondering about the shared library packaging requirements in Policy >> for the special case of scientific libraries that are not intended to be >> used by applications, but are to be used by end-users directly, > > What does "to be used by end users directly" mean? That they will use them to > compile programs? That's not special. Because they are used for compiling, > most shared libraries are Build-Depends of other packges, but that's not the > only reason they exist. All libraries are available for developer end users.
It's less of a library than an environment used for research. Compiling is just a required step to run your code, but applications are usually not distributed in binary form. (Well, not that distributing binaries outside a distribution is fun on Linux anyway ;) ). >> and that do not have a stable ABI. > > That is an issue. It means that upstream will either need to change the > soname > a lot, which is probably not what they do, or that it shouldn't be a shared > library (but a static library instead). Changing the soname often is not an issue; it's just for Debian if the package name changes with the soname... Note that Haskell also doesn't rename packages all the time, but instead Provides: a virtual package which name changes on ABI changes. What I plan to do is similar. >> In particular does splitting out the shared library package provide >> anything useful here? It means additional work for no benefit I can see >> as parallel installation of multiple versions would require having >> multiple -dev packages as well to be useful... > > The benefit of changing the soname and package name of a shared library is not > that multiple versions can be used for development, but rather that programs > compiled against an incompatible old version will still work when the new > version is installed. This is because the old version is not uninstalled from > the system (even if it may be removed from the archive after the dependency is > upgraded there; the old application still links to the old library, which will > remain installed on the user's machine at least until that application is > upgraded or removed). I see no problem with forcing users to recompile their applications; they usually already do so all the time anyway. So, I still plan to drop the extra library packages and just move the shared library to libdune-*-dev. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a91f7c.1090...@debian.org
