Re: Packaging certain libraries as "end-user software"

[Ansgar Burchardt <ansgar@debian.org>]

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