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

ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)

J. H. M. Dassen writes:
> The default Linux binary format is to move to ELF. Most of the libraries
> and other support is already debianized, but uses non-standard locations.
> In the long term, we want users to be able to remove the a.out libraries,
> binutils etc, once all their binaries are ELF.

This is true.

I think that as the dpkg maintainer I probably have a reasonably good
idea of how we can go about this so as to maintain minimum problems:

1. Firstly, we make sure that all our a.out packages have a Depends
line that refers to the a.out libc in some way.  We're still behind on
this, but it ought to be done, IMO.  Certainly all the base packages
need this to prevent serious accidents.

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:
 set -e
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.

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.

4. The ELF packages are renamed to `libc' and made to conflict with
the old versions.  NB that they don't conflict with the new a.out-libc

We'll have to tell the users to upgrade the libc first, but that's
inevitable, I think.  Alternatively, they should be able to just run
the upgrade twice, ignoring the errors the first one throws up (though
it might get to the point where dpkg gives up).

> - The dpkg database does not distinguish between ELF and a.out binaries,
>   so it cannot be used to decide if a.out-library removal is possible.

It could do, if the packages used the dependency feature to indicate
which library they needed.

>   Furthermore, users may have "unregistred" binaries e.g. in /usr/local.
>   The best solution is probably to have a script using 'find' and 'file'
>   to determine if the a.out libraries can be removed.

I'm not convinced this is necessary.  We should probably keep the
a.out-libc package for quite a while, and most people won't want to
deinstall it for ages.


Reply to: