Re: ELF conversion
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 <david@ods.com>
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 <david@ods.com>
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.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: