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?
Thanks,
Bas
Reply to: