I moved these first few parts to the beginning to get them out of the way since they're really side issues.
> > I suppose this explains why > > dpkg doesn't squawk at me when I temporarily downgrade ld.so for > > testing when I know the elf-* packages explciitly require a > > semi-current version. > > I think your dependencies must say something other than what you think > they say, or possibly you're running dpkg with the `allow breaking of > depending packages' flag. dselect sets this flag by default, because > otherwise certain kinds of changes to package arrangements would be > impossible. Here are two entries from my /var/lib/dpkg/status file. I can switch back and forth between ldso-1.6.7 and ldso-1.7.10 without any warnings from dpkg by simply running 'dpkg -i filename'. What am I missing? Package: ldso Essential: yes Status: install ok installed Priority: required Section: base Maintainer: David Engel <[EMAIL PROTECTED]> Version: 1.7.10 Revision: 1 Conffiles: /etc/ld.so.conf bcdcb23c5d5fb460cee2ce315ef7bd32 Description: The Linux dynamic linker, library and utilities. The dynamic linker provides the user-level support for loading and linking DLL and ELF shared libraries. It is required by any program that uses shared libraries, which is just about all of them. Package: elf-libc Status: install ok installed Maintainer: David Engel <[EMAIL PROTECTED]> Version: 5.2.7 Revision: 1 Depends: ldso (>1.7.4-1) Conflicts: elf-gcc (2.7.0-1), elf-gcc (2.6.3-1) Description: The Linux C library version 5 (ELF). > > > Yuk. Why can't we use a sensible location, such as /usr/lib/a.out/* > > > (and /usr/bin/a.out/* if we need it) ? See what the FSSTND has to say > > > about things that think they need a directory right under /usr. > > > > Because $prefix/i486-linuxaout is the standard directory where the GNU > > development tools expect to find a.out files on an ELF system. > > Then the GNU development tools are broken, surely ? I don't think so. With ELF now being the default, a.out is considered a cross-environment. Why should the GNU tools handle it any differently from other cross-environments? > > I > > don't know if the FSSTND has even addressed this yet, but I'm > > confident they would sanction it, at least as a short term solution > > during the transition. > > The transition to a.out is not a short term thing. I still have > libraries on my system that date from my initial installation 3 years > ago; I do not want to have to live with a horrible /usr/i486-linuxaout > directory for what may turn out to be the best part of a decade ! > > I think that making assertions about what the FSSTND group would and > would not sanction is probably unwise. Surely, we've got a few FSSTND participants besides you lurking here. Dan Quinlan, are you out there? > > > `Depends' lines won't stop you replacing an earlier version of a > > > package whose dependencies were satisfied with a newer one shose > > > dependencies aren't. > > > > What! Are you telling me that dependencies aren't checked when > > already installed packages are replaced? > > You have to think about *which* dependencies are checked. Say that > foo 2.0 and bar 2.0 are both installed, and bar 2.0 depends on foo 2.0 > or later. > > Now, if I ask to install foo 1.0, dpkg will complain that this would > break bar, and would either (depending on the flags) deconfigure bar > before replacing foo in the hope that a more suitable combination of > foo and bar will turn up later, or refuse to install the older foo. OK, this is more or less what I would expect. > However, if I try to install bar 3.0, which depends on foo 3.0, dpkg > will replace the existing bar - thinking that foo 3.0 must be on its ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > way at some point (dselect would have been complaining if foo 3.0 ^^^^^^^^^^^^^^^^^ > weren't available at all) - and then fail to configure bar if foo 3.0 > wasn't installed by the end of the run. > > This is fine if bar isn't a critical package, without which none of > the installation tools will work. Usually the user will just do an > installation/upgrade run, and if all the files are there everything > will just work, regardless of the order (say) they inserted the > floppies. If some files are missing they'll discover the problem and > have to get them before the installation/upgrade can be completed. I don't agree that this is a safe assumption, but I can see where it is desirable (maybe even necessary) to have dselect work efficiently when installing a large number of packages. > > I'm sorry, but this not only seems plainly wrong, but can be very > > dangerous as well. I thought the whole point of having dependencies > > was so that users had to install in the proper order. How do you > > expect them to know what order to do things when order is required? > > Word of mouth? > > With respect to ordering - there are other purposes - the point of the > dependency scheme is to ensure that the user (FTP site, whatever) can > feed the packages to dpkg in any order, and dpkg will figure out which > order to do the *configuration*. > > dpkg doesn't usually force packages to be *unpacked* in a particular > order, because this is too hard for the user and unnecessary anyway. > > However, here (with base packages) we have an exception, because a > broken base package will mean that the installation/upgrade will fall > over because of the missing pieces before the missing pieces are > processed. > > The way I'm proposing that we solve this problem is to require the > user to do *only this* upgrade in a particular order. The way I'm > proposing to enforce this is to have the packages' preinst scripts do > a check that will cause the installation/replacement to abort if the > requirement isn't satisfied. The way I'm proposing to tell the users > about it is to tell them in the usual way: announcements to mailing > lists and newsgroups, error messages, documentation, &c. OK, but why even let the installation get to the preinst script? How about we add a new dependency field in the control files which tells dpkg that the specified packages/versions must already be completely installed (unpacked *and* configured) before installing the new package? This seems *much* cleaner to me and won't clutter up some directory with a bunch of xyz-available links to /bin/true. > > > However, more directly to the point of moving elfward, I like Ian's > > > suggestion about a elf-available(8) test during preinst of elf-dependent > > > (elfish?) packages. It seems clean, simple, and effective to me. > > > > Perhaps, but just for this one, single, isolated case. > > > > I think you are focusing too much on the change of binary formats > > (a.out to ELF). Don't forget that there is a fundamentally, much > > bigger change going on as well (libc-4.x to libc-5.x). I hope > > libc-6.x and X11R7 are still a long ways away, but they will happen > > eventually. Why can't we plan ahead now so that we can make these > > types of transitions easier in the future? Surely we can do better > > than the xpkgR5/xpkgR6 mess we had a while back. > > Yes, I'm not proposing xpkgR5/R6-like arrangements. > > Perhaps the script should be called libc5-available. Then when we > make the transition to libc6 we just do the same thing again. > > The X libraries are not a problem and do not require any of these > special mechanisms, because they're not necessary for the package > tools to operate. I disagree. The eventual problem with the X libraries is *very* similar to the current problem with libc. Just because the X packages aren't essential to keeping the system running, doesn't mean we shouldn't try to make the upgrade procedure any less fool-proof. David -- David Engel Optical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081