[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
 /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 Engel                        Optical Data Systems, Inc.
david@ods.com                      1101 E. Arapaho Road
(214) 234-6400                     Richardson, TX  75081

Reply to: