Ian J. writes: > 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.
Certainly. But please don't assume anything about packages that do not have this Depends line. The current ELF packages are undistinguishable from a.out package in the dpkg database. > 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. Does it have to be /lib? If so, do we get clashes with the ELF libs once we convert the base to ELF? BTW almost all of the current base compiles for ELF, so this conversion is almost only a matter of packaging. > > 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. I didn't mean to remove the a.out libraries from the distribution ASAP, I meant to make it easy for users to remove the a.out libraries from their system as soon as no binary depends on them. Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan
