[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Sun, Jul 19, 2015 at 11:06:45AM +0200, Eduard Bloch wrote:
> > > 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.
> > 
> > What is the benefit of providing a shared library at all?  Why not ship only a
> > static library?
> This is not a rhetorical question, is it?

No.  There's a maintainance burden to properly ship a shared library, and if it
doesn't have a stable interface, it is significant.  From the description I
understand that this work may not be done.  The question then becomes: do you
want a shared library that isn't properly handling its interface, or do you
want to waste a little hd space for built binaries?

Unless you are building for embedded systems with very tight resources, a few
MB of hd space is irrelevant.  Using a shared library the way you propose
allows for programs to stop working on upgrade without understandable error
messages.  That's a downside, even if it's small because it doesn't happen
often.  But there is no real upside to shipping a shared library, AFAICS.

> The obvious benefit is the whole principle of a library: common code is
> shared across multiple binaries. I prefer a lib of 2MB size and 5x
> executable (100kB each) over 10MB.

The main benefit of a library is that you don't have code duplication.  With a
static library, the downside is that you need to recompile if you want to use
the new ABI-compatible version of the library (if it's not compatible, you need
to recompile no matter what you use).  If the user recompiles everything all
the time anyway, that isn't a downside.

> The package size might still be ok (xz works well on duplicated code)
> but the installed size isn't.

Executables in a package?  I thought this was for local use only, not for
building packages?  If packages make any sense (whether in Debian or not), then
it's a really bad idea to change the ABI without changing the SONAME, and that
will happen with an unstable ABI.

> > > Changing the soname often is not an issue; it's just for Debian if the
> > > package name changes with the soname...
> > 
> > It's not a problem if the SONAME is changed a lot.  The problem is that it
> That's a "problem" that has made me wondering for years. We are
> over-complicating things; we interpret the simple fact of "has a SONAME"
> as an obligation to make the thing available to all potential users of
> that library... even if there are no users who care!

A SONAME is a form of technical documentation.  It is a note saying "this is
the version of the symbols in here".  If a library has a SONAME, users may
expect it to be properly used.  If you don't want to use it, then don't put it
in there.

You can create a shared object without a SONAME if you want to; that's called a
module and they can be loaded with dlopen.  You need your own method of
handling versions then.

In this case, I don't think modules make sense.  A static library seems more
appropriate.  But it is an option.

> And won't care in future because it's clear that upstream is not using a
> stable API.

So if they aren't, why would they put in a SONAME, which means "we take care of
handling versions well"?  That just confuses people.  If you don't care, then
don't put that in the library.  Trying to install such a module into the
library path will give you a lintian error, and rightfully so.

> If it isn't clear, than making it clear should be the easier mission.

You're proposing to put up a sign claiming that you follow a standard, with a
note saying "not true" on it.  Why don't you remove the sign?


Reply to: