Bug#83669: Shared libraries
Brian May [EMAIL PROTECTED] writes: Jason Does anyone know *why* libtool requires this? It strikes me Jason as totally unnecessary for runtime linking on linux. Maybe Jason someone should fix libltdl. Lets not get off-topic into a flame war over why does libtool do it this way? please. Jason's is actually a valid question concerning this thread. -- Marcelo
Bug#83669: Shared libraries
Marcelo == Marcelo E Magallon [EMAIL PROTECTED] writes: Marcelo Jason's is actually a valid question concerning this Marcelo thread. Well, sorry if I misunderstood the question, but I interpreted it as why does libltdl need libx.la instead of loading libx.so directly? Well, when libltdl loads libx.la, it knows that libx.so depends on liby.so, so it can load that library too. (Also it is more consistent because some OS don't support library interdependencies) So now we start heading off topic with questions like: why can't the interdependencies be included directly in libx.so? which are answered with answers like because current versions of libtool have problems dealing with library interdependencies. So, as I said before, I don't see how any of this is relevant to the original bug report by Ian, so I didn't discuss it earlier. Then again, I now realize that *.la files conflicting is a totally separate issue, so I probably should have bought it up at a different time. -- Brian May [EMAIL PROTECTED]
Re: Bug#83669: Shared libraries
On 5 Feb 2001, Brian May wrote: Marcelo Jason's is actually a valid question concerning this Marcelo thread. Well, sorry if I misunderstood the question, but I interpreted it as My question was retorical. I know the answer is 'because it is too lame to become a no-op on SUS conforming systems'. The relevance is that if libtool is causing a problem for IWJs proposal then the solution is to fix the hack, not hack around the hack with another more brutal hack. Jason
Bug#83669: Shared libraries
Brian == Brian May [EMAIL PROTECTED] writes: Brian foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so - Brian libfoo.so.2.1 For everyone concerned: versions of libtool already support this. eg. cvs version of libtool 1.4, and cvs tree for libtool 1.3x (not sure if includes the latest release of libtool or not, it definitely includes the libtool CVS version under projects/experimental, as Heimdal already uses the new system). lrwxrwxrwx1 bam users 14 Feb 5 12:36 libl4.so - libl4.so.0.0.0* lrwxrwxrwx1 bam users 14 Feb 5 12:36 libl4.so.0 - libl4.so.0.0.0* -rwxr-xr-x1 bam users 12970 Feb 5 12:36 libl4.so.0.0.0* which is exactly what was proposed here. -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
Frank == Frank Belew [EMAIL PROTECTED] writes: Frank --snip -- You have to watch this one. We've found that Frank things like rep require the la in the main package, not the Frank dev due to linking to libltdl. This one was somewhat hard Frank to discover since everyone always seems to have the -dev Frank package installed as well. In that case, consider a possible solution: libx.la is renamed by debian/rules to libx.la.1.2.3 At postinst of non-dev package: ln -sf libx.so.1.2.3 libx.so.1 ln -sf libx.la.1.2.3 libx.la This way neither libx.so.1 or libx.la will conflict. The sym-link is adjusted/removed, as required when the package is removed. However, (I need to check this) libx.la needs to refer to the oldest library (oldest minor version; major version is the same), and libx.so.1 needs to refer to the newest library, this is so things will work correctly for link-time and run-time. (probably some dh_* helper program would do this stuff automatically so individual maintainers do not have to worry.) -- Brian May [EMAIL PROTECTED]
Re: Bug#83669: Shared libraries
On 4 Feb 2001, Brian May wrote: Frank --snip -- You have to watch this one. We've found that Frank things like rep require the la in the main package, not the Frank dev due to linking to libltdl. This one was somewhat hard Frank to discover since everyone always seems to have the -dev Frank package installed as well. In that case, consider a possible solution: Does anyone know *why* libtool requires this? It strikes me as totally unnecessary for runtime linking on linux. Maybe someone should fix libltdl. Jason
Re: Bug#83669: Shared libraries
Jason == Jason Gunthorpe [EMAIL PROTECTED] writes: Jason Does anyone know *why* libtool requires this? It strikes me Jason as totally unnecessary for runtime linking on linux. Maybe Jason someone should fix libltdl. Lets not get off-topic into a flame war over why does libtool do it this way? please. This threadbug report is on a specific proposal to allow compiling of programs against one version of the library, while another version is used for run-time. (same major version). -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
Frank == Frank Belew [EMAIL PROTECTED] writes: Frank --snip -- You have to watch this one. We've found that Frank things like rep require the la in the main package, not the Frank dev due to linking to libltdl. This one was somewhat hard Frank to discover since everyone always seems to have the -dev Frank package installed as well. How many packages use *.la files for run time? 1? Under 5? Under 10? My guess is that the number of packages is so small, that the best solution might be to separate the *.la and *.so files into a separate package (I think the *.so sym-link is required too)[1]. That way, multiple versions of the library don't conflict and can be installed at the same time, but normal users don't have to install the -dev package either. -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
Brian == Brian May [EMAIL PROTECTED] writes: Brian However, this exposes other issues, since the version of Brian *.la required depends on the version of the library Brian required, however only one copy of the *.la file can be Brian installed, while a number of different versions of the Brian shared library can be installed at the same time. I have done a bit more research on this topic (further results still to come), and it seems that the *.la file won't be so much a problem as I originally though - just put it in the -dev package, and everything should be fine. In theory, the *.so file could be a problem. Are there any packages that link to libx.so.2, and then try to dlopen(libx.so)? If so, then the dlopen might use the wrong version of the library. I can't imagine why a program would want to do this though, and even if it does, it seems the solution is to use libltdl to dlopen(libx.la) instead, which will automatically do the right thing (that is use the latest version of the library). -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
On Sat, 27 Jan 2001, Brian May wrote: Henrique == Henrique M Holschuh [EMAIL PROTECTED] writes: Henrique In other words, if this bug is deemed to be correct, we Henrique will have to add hard-link support to dpkg and Henrique .debs. Anything else will simply DOUBLE the already hard-link support will not help any more then sym-links currently do. If one is going to have two copies of the library, one in the runtime and other in the -dev package, they do. And doing this in the maintainer scripts would be just too damn messy. However, Herbert's proposal does not require two copies of the library at all, and I wouldn't have even posted this had I read his mail before replying ;) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#83669: Shared libraries
Herbert Xu [EMAIL PROTECTED] writes: and allow shlibs with different minor version numbers to be installed together by encoding it into the package name. Of course, we'll have to manage /usr/lib/libfoo.so.2 dynamically as well. Break the second you run ldconfig. Plus the fact that the dynamic linker doesn't know about major and minor version numbers, only about sonames. -- Marcelo, *blink*ing.
Bug#83669: Shared libraries
Brian May [EMAIL PROTECTED] writes: If so, what is the problem with installing the unstable version of libl6? Oh, you explain it here. Ian L-dev from unstable, but then when you compile S it ends up Ian needing the L from unstable. Ugh. I finally understand the intention behind this. It's broken. libfoo-dev (2.1-1) was compiled with libbar-dev (1.1-1). libbar1 (1.1-1) exists in unstable and libbar1 (1.0-1) exists in stable. Due to bad judgement, libbar1 (1.1-1) (and libbar-dev 1.1-1 according to this proposal) contains one extra function (wrt to 1.0-1) which libfoo-dev (2.1-1) uses. That means libfoo-dev (2.1-1) depends on libbar1 (1.1-1), or is it libbar-dev (1.1-1) according to this proposal? If this is not the case you are trying to solve, then I'm wrong and I didn't understand the intention. And exactly what do you want to do with the soname in libfoo.so? You can't just hide it from ldconfig, can you? -- Marcelo
Bug#83669: Shared libraries
Marcelo E. Magallon [EMAIL PROTECTED] wrote:
Herbert Xu [EMAIL PROTECTED] writes:
and allow shlibs with different minor version numbers to be installed
together by encoding it into the package name. Of course, we'll have
to manage /usr/lib/libfoo.so.2 dynamically as well.
Break the second you run ldconfig. Plus the fact that the dynamic
linker doesn't know about major and minor version numbers, only about
sonames.
Not if you manage it through ldconfig. BTW, ldconfig does know about
version numbers. Read the source.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: Shared libraries
On Fri, Jan 26, 2001 at 08:34:07PM -0600, David Engel wrote: On Fri, Jan 26, 2001 at 03:04:22PM -0500, Ben Collins wrote: Can we say archive, system, mirror and update bloat horror!? DO you My very rough estimate would be about 300 MB per distribution. Not insignificant, but not completely untenable either. If you said 300 Megs per dist per arch, I can believe that. Which means several gigs over the whole archive. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Bug#83669: Shared libraries
On Sat, Jan 27, 2001 at 01:40:48AM +, Ian Jackson wrote: Ben Collins writes (Bug#83669: Shared libraries): On Fri, Jan 26, 2001 at 07:34:08PM +, Ian Jackson wrote: foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so (copy of actual library) Can we say archive, system, mirror and update bloat horror!? DO you realize what this would mean for lib packages like xlibs and libc6? Could you please be more specific ? I thought it was pretty obvious, but I'll explain. If the libc-2.2.1 is 1.1 megs, then the -dev package will increase by 1.1 megs if I follow your plan. Which means people have to download 1.1 megs more to do upgrades, and the archive will grow by 1.1 megs times the number of archs (so in this case, abount 10Megs). libc.so.6 is only one library (there are lots more in the libc6 package, which means the growth due to just libc6-dev would be closer to 20 megs). I think your setup is completely broken, since it will be linking against one version of the library, yet running against another (remember the runtime in your scenario will now be different than the link time one). But we *already* support linking against one version and running with another. That's the whole point of shared libraries. In particular, it will make it possible (not essential, but possible) to build binaries against an older version of the library than you currently have installed; this will produce binaries which will work both with that older library on other systems, and of course (given that ABI's are supposedly upward-compatible) with the one you have installed. Not in the same sense. We support building and linking with the same library that we run against *at that moment*. If I compile something right now against libc6, and then run it, I am running against the same version as I compiled against. Now, if I have libc6_2.1.3-1, and I upgrade libc6-dev to 2.2.1-1, then I can now compile for libc6 2.2.1-1, but I cannot execute the binaries, because the symbols I need will not be in the runtime libc.so.6 library. So I have not tested this binary can actually run using the library I built it against. Have you never had the experience of a system running stable which needs just one package from unstable ? You have to install the libc from unstable, so you have to install the libc-dev from unstable, so you have to install the libfoobar-dev from unstable for nearly every foobar, so you have to install the libfoobar from unstable for nearly every libfoobar, and suddenly the system isn't running stable any more. So? This makes things consistent, and much easier to track bugs and problems. Your proposal would make things really difficult to track bugs The bug only shows up when I have libfoo1_1.0 and libfoo-dev_0.9 installed. This puts too much load on the maintainer. This is bad, and creates plenty of problems due to the inconsistencies you create. If we encourage maintainers to link against libraries for which they cannot test the runtime, then you are asking for plenty of untested packages ending up in the distribution. I'm not saying that maintainers should routinely usually have different -dev and runtime packages installed. On the contrary, a testing system should have the latest versions, which will correspond. I don't understand what you mean by `link against libraries for which they cannot test the runtime'. Explained above. Just because you don't suggest maintainers do this, doesn't mean they wont try. They could potentially try compiling for unstable, even though they still run stable. They wont be able to test the packages, since their runtime doesn't support that. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Bug#83669: Shared libraries
Herbert Xu [EMAIL PROTECTED] writes: and allow shlibs with different minor version numbers to be installed together by encoding it into the package name. Of course, we'll have to manage /usr/lib/libfoo.so.2 dynamically as well. Break the second you run ldconfig. Plus the fact that the dynamic linker doesn't know about major and minor version numbers, only about sonames. Not if you manage it through ldconfig. I don't think I understand what you mean by manage here. You can't prevent users from running 'ldconfig'. If you run 'ldconfig' it will read the sonames and place symlinks to the newer versions of the library. BTW, ldconfig does know about version numbers. Read the source. It doesn't. It parses the soname, it's not quite the same. And I said dynamic linker not ldconfig. The dynamic linker does not know about version numbers. -- Marcelo
Bug#83669: Shared libraries
Marcelo E. Magallon [EMAIL PROTECTED] wrote:
I don't think I understand what you mean by manage here. You can't
prevent users from running 'ldconfig'. If you run 'ldconfig' it will
read the sonames and place symlinks to the newer versions of the
library.
If you've got both foo 2.0 and foo 2.1 installed, ldconfig will symlink
foo 2.1 it to foo.so.2 which is exactly what you want.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: Shared libraries
Marcelo == Marcelo E Magallon [EMAIL PROTECTED] writes: Marcelo libfoo-dev (2.1-1) was compiled with libbar-dev (1.1-1). Marcelo libbar1 (1.1-1) exists in unstable and libbar1 (1.0-1) Marcelo exists in stable. Due to bad judgement, libbar1 (1.1-1) Marcelo (and libbar-dev 1.1-1 according to this proposal) Marcelo contains one extra function (wrt to 1.0-1) which Marcelo libfoo-dev (2.1-1) uses. That means libfoo-dev (2.1-1) Marcelo depends on libbar1 (1.1-1), or is it libbar-dev (1.1-1) Marcelo according to this proposal? Lets take your example (before hand we would have considered libfoo as an application, not a library, but this will still work): There are two cases: 1. programs that compile using libfoo2 do not use functions from libbar1 stable -- libbar1(1.0-1) libbar-dev (1.0-1) depends libbar-dev (=1.0-1) libfoo2(2.1-1) depends libbar1 libfoo-dev (2.1-1) depends libfoo-dev (=2.1-1) unstable libbar1(1.1-1) libbar-dev (1.1-1) depends libbar-dev (=1.0-1) libfoo2(2.1-1) depends libbar1(= 1.1-1) libfoo-dev (2.1-1) depends libfoo-dev (=2.1-1) I will assume libfoo2 does not need to be changed, because it can check if the new function exists or not using a configure test. Remember, that libfoo2 will correctly have the correct depends: as this comes from the shlibs information in libbar1 (which I assume to be correct). 2. programs that compile using libfoo2 require functions from exactly the same version of libbar1 (consider the case where libbar1 is glibc, and *is* be important) AFAIK It is not possible to set the build-depends automatically to the correct value, but this is a problem with the existing build system, and this proposal doesn't change that limitation in anyway, in fact, this example is based on the existing system (it should really be determined based on the version of libbar1 used). Marcelo And exactly what do you want to do with the soname in Marcelo libfoo.so? You can't just hide it from ldconfig, can Marcelo you? Don't you mean libbar1? Now you have got me confused. -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
Marcelo == Marcelo E Magallon [EMAIL PROTECTED] writes: Marcelo I don't think I understand what you mean by manage here. Marcelo You can't prevent users from running 'ldconfig'. If you Marcelo run 'ldconfig' it will read the sonames and place Marcelo symlinks to the newer versions of the library. This is only a problem if it modifies the symlink used for compilation (libfoo.so). It doesn't matter about the other symlink (libfoo.so.2), as this is used at run time, and the newer minor-versions of the library are meant to be 100% backward compatible with existing source (otherwise the major number would be incremented). That is, if my understanding is correct (please correct me if I am wrong): 1. If you delete a function in the library: = might break existing programs = increase major version 2. If you add a new function in such a way that old software will continue to work: = existing programs won't break = increase minor version = programs compiled for this new version won't work with the old version This I believe is standard libtool behaviour (although I haven't double checked) although libtool has uses different terms. For the 2nd case, you can't just increment the major version, this will break existing software, even though the library is backward compatible. I hope that clears up some confusion over version numbers (which admittedly I am only just beginning to understand myself). -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
Ben == Ben Collins [EMAIL PROTECTED] writes: Ben So? This makes things consistent, and much easier to track Ben bugs and problems. Your proposal would make things really Ben difficult to track bugs The bug only shows up when I have Ben libfoo1_1.0 and libfoo-dev_0.9 installed. This puts too much Ben load on the maintainer. If done properly, the maintainer only need to know if the user is trying to compile an application (libfoo-dev is used) or trying to run an application (libfoo1 is used). Might be confusing the package a is compiled based on an older version of libfoo-dev, but executed with the newer version of libfoo1, but still it should be easy to realize what is happening (just stick to the previous rule). *.la files will be a problem, as explained in my other message. -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
Package: debian-policy Version: 3.2.1.2 (We've had this argument before, and it degenerated into the policy process row. It seems that Wichert is unwilling to act to fix the process, so I'll just reopen the issue like this. I can't find it in the archives anywhere.) Currently, wrt shared libraries, we mandate (or do) this: foo2 (2.1) /usr/lib/libfoo.so.2 - libfoo.so.2.1 /usr/lib/libfoo.so.2.1 (actual library) foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so - libfoo.so.2 The effect is that foo-dev (2.1) has to have a dependency on foo2 (2.1) because otherwise you might compile against a .so file and headers from different versions. This is bad because it makes it hard to upgrade your runtime environment to run new versions of things without also making your compilation environment generate new and incompatible binaries. We can and should fix this by doing this instead: foo2 (2.1) /usr/lib/libfoo.so.2 - libfoo.so.2.1 /usr/lib/libfoo.so.2.1 (actual library) foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so (copy of actual library) Now foo-dev (2.1) doesn't need to Depend on any particular version of foo2; = 2.1 will do. So you can upgrade foo2 without breaking your foo-dev. We should try to do this sooner rather than later, because it's straightforward and almost entirely a good thing. The only downside is that the -dev package wastes some disk space if it happens to be the same version as the shlib package. Ian.
Bug#83669: Shared libraries
On Fri, Jan 26, 2001 at 07:34:08PM +, Ian Jackson wrote: foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so (copy of actual library) Can we say archive, system, mirror and update bloat horror!? DO you realize what this would mean for lib packages like xlibs and libc6? I think your setup is completely broken, since it will be linking against one version of the library, yet running against another (remember the runtime in your scenario will now be different than the link time one). This is bad, and creates plenty of problems due to the inconsistencies you create. If we encourage maintainers to link against libraries for which they cannot test the runtime, then you are asking for plenty of untested packages ending up in the distribution. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Bug#83669: Shared libraries
Ian Jackson [EMAIL PROTECTED] wrote:
Currently, wrt shared libraries, we mandate (or do) this:
foo2 (2.1) /usr/lib/libfoo.so.2 - libfoo.so.2.1
/usr/lib/libfoo.so.2.1 (actual library)
foo-dev (2.1) /usr/include/foo.h
/usr/lib/libfoo.so - libfoo.so.2
How about
/usr/lib/libfoo.so - libfoo.so.2.1
and allow shlibs with different minor version numbers to be installed
together by encoding it into the package name. Of course, we'll have
to manage /usr/lib/libfoo.so.2 dynamically as well.
This would require changing how dpkg-shlibdeps works though.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: Shared libraries
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian The effect is that foo-dev (2.1) has to have a dependency on Ian foo2 (2.1) because otherwise you might compile against a .so Ian file and headers from different versions. Ian This is bad because it makes it hard to upgrade your runtime Ian environment to run new versions of things without also making Ian your compilation environment generate new and incompatible Ian binaries. I am afraid I don't see the problem. When a new version of the library is released that has incompatible changes, it should be released as libfoo3. Even after libfoo3 is installed, programs will continue using libfoo2 without any problems until they are recompiled for libfoo3. The problem is? You seem to imply that the versions of the libraries are incompatible, despite having the same major version. If this is really the case, I think the potential exists to break a lot more then just the build process. Please give me a real life example of why distinguishing libraries solely by their major version number is not good enough... -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
* Brian May [EMAIL PROTECTED] [010126 15:32]: Please give me a real life example of why distinguishing libraries solely by their major version number is not good enough... How does this work with the glibc mess I seem to recall from about a month ago? -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Bug#83669: Shared libraries
Seth == Seth Arnold [EMAIL PROTECTED] writes: Seth How does this work with the glibc mess I seem to recall from Seth about a month ago? I don't recall the details - can somebody please give me a URL? -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
Brian May writes (Re: Bug#83669: Shared libraries): You seem to imply that the versions of the libraries are incompatible, despite having the same major version. If this is really the case, I think the potential exists to break a lot more then just the build process. Please give me a real life example of why distinguishing libraries solely by their major version number is not good enough... In general, it's not safe to use a minor version of a library lower than that with which the binary was compiled. So you if you have a library L used by both an program S which you want to compile for stable and a program U you want to try out from unstable, then you have to install the L from unstable (because U is compiled against it), and because the versions of L and L-dev have to match, you have to have the L-dev from unstable, but then when you compile S it ends up needing the L from unstable. The net effect is that nearly all packages in Debian are compiled against the libraries from unstable, and that it's hard for a developer running mostly unstable to build packages for stable. Ian.
Bug#83669: Shared libraries
Ben Collins writes (Bug#83669: Shared libraries): On Fri, Jan 26, 2001 at 07:34:08PM +, Ian Jackson wrote: foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so (copy of actual library) Can we say archive, system, mirror and update bloat horror!? DO you realize what this would mean for lib packages like xlibs and libc6? Could you please be more specific ? I think your setup is completely broken, since it will be linking against one version of the library, yet running against another (remember the runtime in your scenario will now be different than the link time one). But we *already* support linking against one version and running with another. That's the whole point of shared libraries. In particular, it will make it possible (not essential, but possible) to build binaries against an older version of the library than you currently have installed; this will produce binaries which will work both with that older library on other systems, and of course (given that ABI's are supposedly upward-compatible) with the one you have installed. Have you never had the experience of a system running stable which needs just one package from unstable ? You have to install the libc from unstable, so you have to install the libc-dev from unstable, so you have to install the libfoobar-dev from unstable for nearly every foobar, so you have to install the libfoobar from unstable for nearly every libfoobar, and suddenly the system isn't running stable any more. This is bad, and creates plenty of problems due to the inconsistencies you create. If we encourage maintainers to link against libraries for which they cannot test the runtime, then you are asking for plenty of untested packages ending up in the distribution. I'm not saying that maintainers should routinely usually have different -dev and runtime packages installed. On the contrary, a testing system should have the latest versions, which will correspond. I don't understand what you mean by `link against libraries for which they cannot test the runtime'. Ian.
Bug#83669: Shared libraries
On Fri, Jan 26, 2001 at 03:04:22PM -0500, Ben Collins wrote: Can we say archive, system, mirror and update bloat horror!? DO you My very rough estimate would be about 300 MB per distribution. Not insignificant, but not completely untenable either. This is bad, and creates plenty of problems due to the inconsistencies you create. If we encourage maintainers to link against libraries for which they cannot test the runtime, then you are asking for plenty of untested packages ending up in the distribution. Not necessarily. In Ian's proposal, the -dev package can never be newer than the run-time package. This means the newly built program will always be run with the library of the same or newer version. We already have to support this situation anyway. On Sat, Jan 27, 2001 at 09:05:14AM +1100, Herbert Xu wrote: foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so - libfoo.so.2 How about /usr/lib/libfoo.so - libfoo.so.2.1 and allow shlibs with different minor version numbers to be installed together by encoding it into the package name. Of course, we'll have to manage /usr/lib/libfoo.so.2 dynamically as well. I think this would be more trouble than it's worth. Not only would packagers have to deal with all of the possible overlaps between packages, it would also potentially add even more packages to the archives. This would require changing how dpkg-shlibdeps works though. Perhaps not. Most situations could probably be handled by simply moving the .shlibs files from the run-time packages to the -dev packages. David -- David Engel [EMAIL PROTECTED]
Bug#83669: Shared libraries
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian In general, it's not safe to use a minor version of a library Ian lower than that with which the binary was compiled. Ian So you if you have a library L used by both an program S Ian which you want to compile for stable and a program U you want Ian to try out from unstable, then you have to install the L from Ian unstable (because U is compiled against it), and because the Ian versions of L and L-dev have to match, you have to have the So lets make up some more details: stable: -- libl6 version 2.1-1 contains: /usr/lib/libl.so.6.0 /usr/lib/libl.so.6 -- /usr/lib/libl.so.6.0 libl-dev depends on libl6 version 2.1-1 and contains: /usr/lib/libl.so -- /usr/lib/libl.so.6.0 progs depends on libl6 and contains: ldd /lib/libwrap.so.0 libc.so.6 = /lib/libc.so.6 (0x4000e000) libl.so.6 = /lib/libl.so.6 (0x) -- unstable: - libl6 version 2.2-1 contains: /usr/lib/libl.so.6.1 /usr/lib/libl.so.6 -- /usr/lib/libl.so.6.1 libl-dev depends on libl6 version 2.2-1 and contains: /usr/lib/libl.so -- /usr/lib/libl.so.6.1 progu depends[1] on libl6 (=2.2-1) and contains: ldd /lib/libwrap.so.0 libc.so.6 = /lib/libc.so.6 (0x4000e000) libl.so.6 = /lib/libl.so.6 (0x) - so progs will work with both versions of libl.so.6.* but progu will only work with libl.so.6.1, as it was compiled based on libl.so.6.1 And you want to install libl-dev version 2.2-1 on a stable system without installing libl6 version 2.2-1 at the same time? Am I right so far? If so, what is the problem with installing the unstable version of libl6? Oh, you explain it here. Ian L-dev from unstable, but then when you compile S it ends up Ian needing the L from unstable. So you want to be able to compile progs based on libl version 2.1-1 and progu based on libl version 2.2-1. You don't want to have to downgrade libl to version 2.1-1 just to install libl-dev 2.1-1, because that would break progu. Your proposal would (supposedly) help by allowing you to install libl-dev version 2.1-1 even though libl6 version 2.2-1 has been installed, so you can compile for the earlier version, while at the same time you can run both progu and progs. (how do you ensure that all -dev packages installed are from stable, and you haven't missed any?) Ok, Thanks, I think I understand now. Note: [1] I hope nobody disputes why this version depends is required... (things might get awkward if it was forgotten). -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
On Fri, 26 Jan 2001, Ben Collins wrote: On Fri, Jan 26, 2001 at 07:34:08PM +, Ian Jackson wrote: foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so (copy of actual library) Can we say archive, system, mirror and update bloat horror!? DO you realize what this would mean for lib packages like xlibs and libc6? I In other words, if this bug is deemed to be correct, we will have to add hard-link support to dpkg and .debs. Anything else will simply DOUBLE the already bloated */lib and the archive. Such doubling is NOT acceptable (IMHO, but it seems that at least BenC agrees with me). And I'm told adding hard-link support to dpkg is severely non-trivial (not to mention the resulting .debs would probably be absolutely non-compatible with older dpkg binaries, which may be a serious issue in itself). Setting up a chroot jail is an acceptable way to deal with the problem for developers (although it can be VERY painful in terms of disk-space), and learning to apt-get source -b is an acceptable way to deal with the problem for users that just 'have' to fetch that single package from unstable, IMHO. Maybe we could work on making these two tasks simpler and properly documented instead? at least we'd have it finished for woody instead of woody+3. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#83669: Shared libraries
Herbert == Herbert Xu [EMAIL PROTECTED] writes: Herbert Ian Jackson [EMAIL PROTECTED] wrote: Currently, wrt shared libraries, we mandate (or do) this: foo2 (2.1) /usr/lib/libfoo.so.2 - libfoo.so.2.1 /usr/lib/libfoo.so.2.1 (actual library) foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so - libfoo.so.2 Herbert How about /usr/lib/libfoo.so - libfoo.so.2.1 and allow Herbert shlibs with different minor version numbers to be Herbert installed together by encoding it into the package name. Herbert Of course, we'll have to manage /usr/lib/libfoo.so.2 Herbert dynamically as well. Seems like a good idea, but it won't work. foo2 (2.0) /usr/lib/libfoo.so.2 - libfoo.so.2.0 /usr/lib/libfoo.so.2.0 (actual library) foo2 (2.1) /usr/lib/libfoo.so.2 - libfoo.so.2.1 /usr/lib/libfoo.so.2.1 (actual library) foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so - libfoo.so.2.0 the problem here is that the two versions of foo2 cannot be installed at the same time (1: conflicting package name; 2: conflicting symlink). However, if you really wanted to, you could have foo2_0 (2.0) /usr/lib/libfoo.so.2.0 (actual library) foo2_1 (2.1) /usr/lib/libfoo.so.2.1 (actual library) foo2 (2.0)/usr/lib/libfoo.so.2 - libfoo.so.2.0 foo2 (2.1)/usr/lib/libfoo.so.2 - libfoo.so.2.1 foo-dev (2.1) /usr/lib/libfoo.so - libfoo.so.2.0 which means that multiple minor versions of the library can be installed at the same time, and the version of foo2 determines which one to be used for run-time, while foo-dev determines which one should be used for compilation. foo-dev is independent of foo2. People might complain about foo2 (do we really need a package containing nothing but a symlink?), but personally I like the idea (compare with task packages which are empty). I think it is simple to understand, and adds little overhead (just foo2). Packages work as normal (installing foo2 2.1 or foo-dev 2.1 for instance would automatically install foo2_1). Comments? -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
On Fri, Jan 26, 2001 at 08:34:07PM -0600, David Engel wrote:
I think this would be more trouble than it's worth. Not only would
That's probably true.
packagers have to deal with all of the possible overlaps between
packages, it would also potentially add even more packages to the
archives.
I thought that Ian's proposal was aimed at allowing such disparities to
exist rather than (necessarily) having them in one distribution. So in the
case of libc6 2.1 and libc6 2.2, potato would have libc6 and libc6-dev
2.1 while woody would have libc6 and libc6-dev 2.2. Having his scheme
would allow you to upgrade your libc6 to the woody version while maintaining
the libc6-dev from potato.
Under the scheme that I described, the same thing can be achieved without
having two versions of the same library existing in either potato or woody.
This would require changing how dpkg-shlibdeps works though.
Perhaps not. Most situations could probably be handled by simply
moving the .shlibs files from the run-time packages to the -dev
packages.
Yes, but this requires changing dpkg-shlibdeps. Besides, it's not exactly
easy to figure out what -L flags were used during the compile and hence find
the correct .so file.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: Shared libraries
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian The net effect is that nearly all packages in Debian are compiled Ian against the libraries from unstable, and that it's hard for a Ian developer running mostly unstable to build packages for stable. The conventional solution for this has been to create chroot jails for stable. Indeed, the strong recommendation has been for developers to run unstable. Note that this can work both ways: you van create an unstable chroot area on a mostly stable box. manoj -- Show me a man who is a good loser and I'll show you a man who is playing golf with his boss. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#83669: Shared libraries
Hi, We seem to be balancing 300MB for all archives, mirrors, transfers, CD's, everyone downloading packages, etc, against the requirements of a few developers who need to create debs for libraries older than those they are running? And who could always create a chroot jail for themselves (I can provide a chroot creation script for those who shall argue that this is too hard). For me, this seems a no brainer, that we don't need the bloat. I agree that laziness is a good programmer trait, but this is taking it too far. Or am I missing the major advantage that over rides the bloat argument? manoj -- There's no future in time travel. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#83669: Shared libraries
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Hi, We seem to be balancing 300MB for all archives, Look at Herbert's proposal - it doesn't require any extra space, except for storing multiple versions of the library (which could be done privately too, if Debian doesn't want to do it). -- Brian May [EMAIL PROTECTED]
Bug#83669: Shared libraries
Brian == Brian May [EMAIL PROTECTED] writes: I previously misunderstood Herbert's proposal, here it is again (I hope it is accurate this time...). foo2.0 (2.0) /usr/lib/libfoo.so.2.0 (actual library) Provides: foo2 version 2.0 foo2.1 (2.1) /usr/lib/libfoo.so.2.1 (actual library) Provides: foo2 version 2.1 foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so - libfoo.so.2.1 the maintainer scripts for foo2.0 2.0 would create /usr/lib/libfoo.so.2 - libfoo.so.2.0 while the maintainer scripts for foo2.1 2.1 would create /usr/lib/libfoo.so.2 - libfoo.so.2.1 That IMHO is probably the best suggestion I have seen so far. Just as long as foo2.1 doesn't conflict with foo2.0 (otherwise you get no benefit)[1]. Data files (eg plugin modules, see libgii0 potato version), may be an issue here. If both foo2.0 and foo2.1 both contain the same data file, they will conflict. Fix (1): put data files in a separate package. Fix (2): if the run-time library requires specific version of the datafile, then the data file needs to be made unique in some way, eg. put in a unique directory. (so multiple versions of the data file can be installed at once). (a combination of these may be used). However, neither of these solutions will help with *.la files that are required at run-time. From the debian-policy, 11.2: Packages that use libtool to create shared libraries should include the .la files in the -dev packages, with the exception that if the package relies on libtool's libltdl library, in which case the .la files must go in the run-time library package. This is a good idea in general, and especially for static linking issues. However, if foo.la file goes into the run-time foo2.0 and foo2.1, then these packages will conflict. Solution: Fix (1), as above. However, this exposes other issues, since the version of *.la required depends on the version of the library required, however only one copy of the *.la file can be installed, while a number of different versions of the shared library can be installed at the same time. Fix (2) could be used here, but this breaks the existing libtool conventions. Note: [1] IMHO the policy suggests that it should be possible to install multiple versions of the library at the same time, but does not require it: If you have several shared libraries built from the same source tree you may lump them all together into a single shared library package, provided that you change all their sonames at once (so that you don't get filename clashes if you try to install different versions of the combined shared libraries package). -- Brian May [EMAIL PROTECTED]
