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#66023: PROPOSAL] Treat plugins and shared libraries differently
On Thu, Jul 06, 2000 at 09:01:02AM +0100, Julian Gilbey wrote: On Thu, Jun 22, 2000 at 03:35:08PM +0200, Josip Rodin wrote: Maybe we should define the default directories that every ld.so.conf file should contain - /lib /usr/lib /usr/X11R6/lib - and mark every other /lib and /usr/lib are always included implicitly, unless ldconfig is told not to include them. On Sun, Jul 09, 2000 at 01:15:19AM +0100, Julian Gilbey wrote: /lib/ld-linux.so. ld.so is used for a.out binaries and ld-linux.so for ELF binaries. I presume there is no equivalent distinction on That's correct, but not complete. More specifically, ld-linux.so.1 is for libc5 and ld-linux.so is for libc6. On Sun, Jul 09, 2000 at 03:11:13PM +0200, Marcus Brinkmann wrote: No, we simply use the ld.so from glibc. It would be great if Linux could also drop the special ld-linux.so and aim at a merger with glibc (I thought this was already attempted in the past, seems my memory is at fault). ld-linux.so.* was chosen so it would not conflict with other systems. This makes it easier setup emulations of other systems on Linux and vice versa. It's not worth changing. David -- David Engel [EMAIL PROTECTED]
Bug#43928: libc and kernel source policy
On Tue, Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote: is actually nothing wrong with this policy. Personally, I would hope that it always stays this way. Ditto. For the non-i386 archs, it makes for much less bug reports, and more stable/consistent builds. FWIW, stability and consistency are the primary reasons I started the current convention a few years ago and those reasons are still valid today. Perhaps the real argument should be, to have something that allows the users to specify their own headers without libc-dev overwriting them. There is -- it's called gcc -I. David -- David Engel [EMAIL PROTECTED]
Re: Bug#32229: PROPOSED] libc-dev dependency in non-libc -dev packages
On Thu, Jan 21, 1999 at 05:33:32PM -0700, Jason Gunthorpe wrote: I guess, logically, a -dev package for a libc6 library should depend on libc6-dev and a -dev package for a libc5 library should depend on libc5-dev, source packages should depend on libc-dev as it hopefully irrelevent which version : I haven't been following debian-* very closely lately so I missed the start of this thread and don't know the exact problem being addressed. However, since I started the -dev package convention way back when I was maintaining libc, perhaps I can add some clarification. The intent for a libfooABC-dev package was to depend on the most explicit name for any other -dev packages it needs, e.g. libbarXYZ-dev. The more generically named libfoo-dev virtual package was only intended to prevent installation of another version of the same -dev package or another conflicting -dev package. The reason libc5-altdev didn't provide libc-dev is because it was installed in a non-standard location so it couldn't conflict with any other libcX-dev. Take a look at my tcl7.6-dev, tcl8.0-dev, tk4.2-dev and tk8.0-dev packages to see how this is done in a real world situation. The dependencies and conflicts are setup to prevent nonsensical installations such as tcl7.6-dev with tk8.0-dev or tcl8.0-dev with tk4.2-dev. David -- David Engel [EMAIL PROTECTED]
Re: /usr/X11R6
On Sat, Aug 29, 1998 at 08:09:06PM -0700, Jim Pick wrote: One argument I've heard is that it makes disk partitioning easier (ie. /usr/X11R6 can be split off to another partition) - but that's not a strong argument, IMHO. That argument is bogus. /usr/lib is considerably larger than /usr/X11R6, at least on all of the systems I deal with. If someone is short of space on /usr, moving /usr/lib to another partition would be a better choice than /usr/X11R6. On Sun, Aug 30, 1998 at 06:00:06PM +0200, Miquel van Smoorenburg wrote: Because every other Unix on the planet uses something similar? Almost everything in Linux has been modeled after those other Unices and that is part of Linux's succes. Uh, Miquel, Solaris doesn't use /usr/Xanything. Instead, it spreads things across /usr/openwin, /usr/dt and possibly even /opt. On Sun, Aug 30, 1998 at 09:23:50AM -0700, Jim Pick wrote: Would it be incompatible if we left the symlinks in? I don't think anybody was suggesting that we take them out. I'm not in favour of anything that would break compatibility. It hasn't been discussed (yet), but I would actually be in favor of eventually removing the compatibility symlinks altogether after allowing sufficient time for everything to be rebuilt and it was shown that nothing would break -- and I am certain that nothing would break. One thing that many people may not realize is that if X was configured to use /usr instead /usr/X11R6, nearly everything else would automatically follow along by simply rebuilding it. The only things that would be left behind, are those which don't use xmkmf or autoconf and instead have hardcoded Makefiles. On Sun, Aug 30, 1998 at 12:20:38PM -0500, Manoj Srivastava wrote: Such a move would, in fact, break section 4.1 of the FSSNTD, and would also violate the FHS. I don't think so! IMHO, the key phrase in that section is This hierarchy [/usr/X11R6] is reserved for the X Window System, version 11 release 6, and related files. My intepreation of this phrase is that nothing except X11R6 may use that directory -- not that X11R6 must use it. This proposal also does not have an ewasy way of transitioning between releases of the X WIndow system (like, release 7, or version 12. In the current method, one may have multple copies of the X window system on the machine simultaneously, keepin one the default, and allowing others to experiment with newer version at will. Also allows an easy roll back by changing 3 links. Sure it does! First, if you're really experimenting, you should put things in an experimental location while you're testing them. You should move things to production locations only after you're satisfied with them. Those of us who mess with test libc's do this all the time. Second, multiple versions of X can coexist just fine in the same hierarchy. It's no coincidence that the directories under /usr/X11R* exactly mirror those under /usr and that the parts that might conflict with other versions of X are in X11-specific directories (e.g. .../include/X11 and .../lib/X11). Give the people who laid out the hierarchy -- they knew what they were doing. On Sun, Aug 30, 1998 at 08:44:43PM +0200, Andreas Jellinghaus wrote: agreed. why don't ask the fhs team why they left the link for this single package ? They probably knew it was a contentious, potentially divisive, issue that they couldn't enforce anyway so they decided to punt on it. We're in a different position because if we do reach consensus on it, we can act on it. On Sun, Aug 30, 1998 at 02:14:32PM -0500, Manoj Srivastava wrote: I want to have both R6 and R7 installed at the same time. I Nobody has suggested that this wouldn't be possible. The only thing that wouldn't easily be possible is to have multiple development environments installed in the default location. If you needed multiple development emvironments, then and only then, would special treatment be needed. Since we already do this for libc5 and libc6, it shouldb't be a big deal. David -- David Engel [EMAIL PROTECTED]
Re: /usr/X11R6
On Fri, Aug 28, 1998 at 06:40:30PM +0200, Andreas Jellinghaus wrote: Wouldn't bother me if we whacked /usr/X11R6 altogether and just moved all its stuff into the FHS-compliant places, and left behind the appropriate symlinks. I have no idea if/how this would break existing stuff, though. i see no reason not why it should not work. the dirs under X11R6 prefectly integrate into /usr. and this solves problems like what to do with share and libexec (X11R6/share or share/X11 ? X11R6/libexec or libexec/X11 ?). two share tree's doesn't make sence to me.. FWIW, this would be my first preference (doing away with /usr/X11R6 altogether). As has already been noted, the current /usr/X11R6 hirerarchy would fit nicely if it were simply moved to /usr. I doubt this is just a coincidence. A symlink from /usr/X11R6 to /usr could be used until the transition was completed. However, I suspect there would be tremendous oppoisition to doing this. On Fri, Aug 28, 1998 at 09:35:00AM +0200, Andreas Jellinghaus wrote: i vote for c) every package that is installed by default into X11 this way X11, fvwm and such stuff will go into X11R6, but tcl/tk, gnome, kde, gvim, and most other stuff will not use it. Taking a more pragmatic approach, this is probably the best way to go. In this case the following rules of thumb would apply. If a package uses xmkmf, use the defaults which would put it under /usr/X11R6. If a package uses autoconf, use --prefix=/usr when running configure which would put it under /usr. David -- David Engel [EMAIL PROTECTED]
Re: changelog vs ChangeLog and policy dictates
On Sat, Apr 11, 1998 at 04:36:14PM -0400, Dale Scheetz wrote: I find the typology of ChangeLog much easier to read than changelog. They parse the same for me, and it is the fact that they don't parse the same for *nix systems that allows them to be of such value, even in this small case. Advice? Dale, I never liked this particular policy either and didn't follow it for a long time. I eventually switched to a compromise solution. I still install a packages ChangeLog file exactly as provided except for posiibly compressing it and add a symlink to it named changelog.gz to comply with Debian policy. David -- David EngelODS Networks [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig or not
On Sat, Mar 28, 1998 at 02:44:05PM +0100, James Troup wrote: Only iff $1 is configure; you do *not* want to run ldconfig if the postinst is called as abort-upgrade|abort-remove|abort-deconfigure, or you can end up with all kinds of nastiness with .dpkg-tmp files as .so links and in ld.so's cache and other fun stuff[1]. This touches on something I've asked for in the past, but not in quite a while. It would really be nice if someone would write sample, skeleton maintainer scripts that explicitly list every case where they may be called from dpkg. The sample scripts should also contain approriate comments describing each case, when and why they might be called and what should and should not be typically done. I know most, if not all, of this information is available in the current dpkg documentation, but that section can be a bit daunting (I know it still is to me). If such sample scripts were available, I think it would be a tremendous help to new developers as well as experienced developers. David -- David EngelODS Networks [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig or not
On Sat, Mar 28, 1998 at 12:12:48AM -0500, Adam P. Harris wrote: [You (David Engel)] This is correct -- you must run ldconfig. If the new libraries are installed into /lib or /usr/lib, you can get away with not running ldconfig but you should still run it anyway to get the entries into /etc/ld.so.cache. Wait a minute. If this is indeed the case, and I'm not convinced it is, Well, since I am the author of ldconfig, I think I have a pretty good idea of how it works with the dynamic linkers. :) we better change my bible, the Debian Packaging Manual, Chapter 12, where it says: | If you do the above your package does not need to call ldconfig in its | maintainer scripts. It is especially important not to call ldconfig in | the postrm or preinst scripts in the case where the package is being | upgraded (see Details of unpack phase of installation or upgrade, | section 6.3), as ldconfig will see the temporary names that dpkg uses | for the files while it is installing them and will make the shared | library links point to them, just before dpkg continues the | installation and removes the links! This issue has come up several times but nobody has ever fixed the Debian documentation. ldconfig should (must if the library is not in /lib or /usr/lib) always be called in the postinst script. The rest about not calling ldconfig from postrm and preinst scripts is correct. David -- David EngelODS Networks [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig warnings
On Fri, Dec 26, 1997 at 11:16:15PM -0500, Joey Hess wrote: Adam P. Harris wrote: Maybe that's not necessary. Rob Browning post got me thinking: even if you create the symlink in `debian/tmp/...', order it properly w.r.t. the actual shared lib, you do still need to call ldconfig in postinst in order to update /etc/ld.so.cache. I belive that is correct. David Engel can tell us for sure. This is correct. Is this the issue? It would be a pretty simple addition to Ch 12 of the Packaging Manual. I don't think it's that simple. Let me quote the manual again: | If you do the above your package does not need to call ldconfig in its | maintainer scripts. It is especially important not to call ldconfig in | the postrm or preinst scripts in the case where the package is being | upgraded (...) as ldconfig will see the temporary names that dpkg uses | for the files while it is installing them and will make the shared | library links point to them, just before dpkg continues the | installation and removes the links! Pay especial attention to the end of that quote. This is a real problem. When I was packaging aalib, I had it call ldconfig. Then, I read this. I slowed my system down to a crawl with some spin loop code, and then installed aalib. While aalib was installing, I ran ls /usr/lib/aalib* repeatedly in another xterm. What I saw happen was just as the policy manual described: as the package installed, dpkg made aalib.so.*.dpkg-tmp files, then ldconfig was run, and symlinks where made pointing to them. This doesn't seem to happen always. Is it a race condition? (I don't see how). Maybe it has to do with if you're upgrading. Anyway, I saw it happen. It's a real problem and we have to figure out a way to deal with it if indeed we need to run ldconfig to make it update ld.so.cache. (One way would be to hack ldconfig to ignore the dpkg .tmp files.) It's not a problem if you don't, as the manual says, run ldconfig from the preinst or postrm scripts. To say it simpler, ldconfig should only be run from the postinst script. David -- David EngelODS Networks [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081
