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 -- 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/20150720233709.gx8...@fmf.nl
