Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
David Engel writes ("Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)"):
> > 2. Secondly, we arrange that all the new base packages have code in
> > the preinst that checks for the existence of the ELF libraries
> > (perhaps by running /usr/bin/elf-available or something). If the
> > libraries aren't found then the preinst returns a non-zero exit status
> > and the upgrade aborts. Say:
> > #!/bin/sh
> > set -e
> > elf-available
> > And elf-available is an ELF version of /bin/true supplied with one of
> > the ELF library packages. Then if elf-available is missing or
> > something else goes wrong we get a message like
> > /var/lib/dpkg/tmp.ci/preinst: elf-available: not found
> > and the installation aborts. If we're feeling fancy we can write
> > code that prints a more helpful message.
>
> 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.
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 could provide a new dpkg control file field to do this, but there
are a number of problems with that, and since only the base packages
are affected by this problem it seems better to deal with the problem
in the way I suggested above.
> > 3. We do a `renaming' operation on the a.out libc package, renaming it
> > to a.out-libc. At the same time we move the a.out libraries inside it
> > to their non-FSSTND locations if appropriate, but we need to keep the
> > ones currently in /lib in the root partition. Eventually this package
> > will be removed from Required - when all the base packages are
> > converted to ELF.
>
> Renaming packages seems rather error prone to me. How would it be
> done? This sure complicates our upgrade procedure -- first upgrade to
> this set of packages, then run this command or install this special
> package which renames things, finally install these other packages,
> etc. Ick!
Renaming packages involves releasing a package with the new name which
conflicts with the old one. There is a bug to do with conffile
handling in this situation, but (a) I'm going to fix it and (b) it
won't affect the libc, because it doesn't have any conffiles.
The user will have to be told to upgrade their libc's first (using `dpkg
--install libc-aout.deb libc-elf.deb' or whatever), and can then use
dselect for the rest of the operation.
> 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.
> Some people have suggested that the
> stuff in /lib be moved to /lib/a.out or similar. This shouldn't be
> necessary as the ELF stuff that goes in here should coexist.
Good.
> Then, build a new release of elf-libc with everything moved from
> /usr/i486-linuxelf to /lib and /usr. This new package should be named
> libc5 (note not libc) and have appropriate conflicts lines with older,
> pre-ELF versions of the libc package.
>
> Finally, so we don't repeat the same mistakes again, any new packages
> built using libc5 should explicitly list it in their dependencies.
Right.
Ian.
Reply to: