Re: ELF conversion
David Engel writes ("Re: ELF conversion"):
> > > > 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?
They shouldn't. In this case IMO all the other cross-environments'
installations are broken too. Last time I looked there was a comment
in the FSSTND that applications shouldn't use directories directly
under /usr, and here we have the GNU compiler set using /usr/<foo> for
many <foo> !
> > > 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?
I'll try to get this discussed by the FSSTND, but there are some
rather heated discussions going on around the proposed BSD merger, and
some people don't seem to like me very much.
> > 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.
> >
> [...]
>
> 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 agree that the assumption isn't necessarily true, but I don't think
there's anyother way of doing this.
> 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.
But these fields would only be used by the base packages, and the base
packages depend on practically nothing except the libc (and sometimes
each other).
If I provide and document such a field all sorts of other packages
will start to use it, which will break people's attempts to do
bulk-upgrade.
> > 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.
No, it isn't. When the new X comes out you can unpack everything in
any order, and dpkg will sort out the ordering when it comes to set
them up. The fact that X will be broken halfway through the upgrade
is unavoidable, unless you either force the user to install things in
a particular order or have some kind of massive `atomic install of
everything' operation.
> 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.
This is true but not relevant. The reason for the special handling of
the libc is that it's required for the package installation tools
to operate. The only problem I'm trying to solve there is the
possibility that the user might upgrade their tar or dpkg or something
when the new libc wasn't there yet, and the solution I'm proposing is
to have that attempt fail.
This is not nice for the user, because it means they have to follow
some special README file to invoke dpkg/dselect in the right way in
the right order on the right files, rather than just being able to run
dselect in the usual way. Unfortunately it's necessary.
This situation does not apply to the X packages, so we can make it
easier to upgrade X than to upgrade the libc: to upgrade X you just
use dselect in the normal way.
Ian.
Reply to: