Re: Packaging certain libraries as end-user software
On 07/19/2015 11:06 AM, Eduard Bloch wrote: ... even if there are no users who care! And won't care in future because it's clear that upstream is not using a stable API. since the sceintific community was mentioned as the background for these users: i doubt whether they won't care *because* it's clear that upstream is not using a stable API. in my experience these¹ are the sort of users who don't care because ... they don't know it better. any promise on a stable API (or not) is kind of lost. which probably makes a good point for static linking. gfmdsar IOhannes ¹ and i consider myself a proud member of this community (probably with a stronger sense about APIs and programming in general...) signature.asc Description: OpenPGP digital signature
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 -- 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
Re: Packaging certain libraries as end-user software
Hallo, * Bas Wijnen [Sun, Jul 19 2015, 04:10:21AM]: On Fri, Jul 17, 2015 at 05:30:04PM +0200, Ansgar Burchardt 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? 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 package size might still be ok (xz works well on duplicated code) but the installed size isn't. 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! And won't care in future because it's clear that upstream is not using a stable API. If it isn't clear, than making it clear should be the easier mission. Regards, Eduard. -- leichenwagenErst wenn der letzte Programmierer eingesperrt und die letzte Idee patentiert ist, werdet ihr merken, daß Anwälte nicht programmieren können -- 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/20150719090645.ga26...@rotes76.wohnheim.uni-kl.de
Re: Packaging certain libraries as end-user software
On Fri, Jul 17, 2015 at 05:30:04PM +0200, Ansgar Burchardt 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? 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... It's not a problem if the SONAME is changed a lot. The problem is that it needs to change a lot and upstream may forget it. If programs need to be recompiled before running anyway, I don't think there's a benefit in shipping a shared library. 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. That is a good idea also when shipping only a static library. 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/20150719021020.gv8...@fmf.nl
Re: Packaging certain libraries as end-user software
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 -- 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/55a91f7c.1090...@debian.org
Re: Packaging certain libraries as end-user software
On 2015-07-17, Ansgar Burchardt ans...@debian.org wrote: So, I still plan to drop the extra library packages and just move the shared library to libdune-*-dev. I'd suggest you set it up with shlibs that ensures that packages built against these libraries aren't installable in the archive. /Sune -- 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/mobhsl$lvt$1...@ger.gmane.org
Packaging certain libraries as end-user software
Hi, 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, and that do not have a stable ABI. 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... I'm considering to move the shared libraries into the -dev package, have lib*-dev Provides: lib*-x.y.z and shlibs generate dependencies on the provided virtual package. While no applications depend on the shared libraries, the virtual packages are needed as the entire framework is split over multiple source packages providing shared libraries with dependencies between them. I'm thinking of dune-* / libdune-*-dev here, but the same probably applies to other packages like deal.ii as well. Does anyone see any problems with this plan? Ansgar -- 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/559e92a8.9080...@debian.org
Re: Packaging certain libraries as end-user software
Hi, 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. 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). 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). This is true regardless of whether the application is provided by Debian or not. (But if it isn't, it is technically easy to remove the old library and break the application; the user must take care not to do that.) Does anyone see any problems with this plan? Yes. The way we handle shared libraries for Debian packages works also for programs that aren't in Debian. Your proposal makes it harder for users to keep their programs running when the library is upgraded (they are forced to recompile). Also, to repeat: if the ABI is very unstable, the library should probably not be distributed as a shared library, but only as a static library. Then all those problems don't exist (but you're also missing some benefits, which is why most libraries should better be shared, with the static version only installed for special cases). 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/20150709163908.gd8...@fmf.nl
