Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
David Engel writes:
> > > This elf-available bit is too klugy for me. Why can't we just use
> > > dpkg's standard dependency checking? Isn't that what it's there for?
> >
> > `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.
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 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.
> > This is necessary so that you can install or upgrade your system in
> > any order. However, what we need to do here is to enforce an order.
>
> 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.
> > > Next, we build a new release of libc that moves everything under /usr
> > > to /usr/i486-linuxaout. This is the standard directory to put a.out
> > > stuff in after switching to 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 ?
The default location ($prefix) for most of the GNU tools is
/usr/local/*, but we quite rightly override that. Why can't we
override their library placements, &c, to look more sensible ?
> 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.
David Engel writes:
> > 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.
Ian.
Reply to: