Re: Packaging certain libraries as "end-user software"
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.