Re: dpkg 1.1.1elf: many changes, more to come

[Ian Jackson <ian@chiark.chu.cam.ac.uk>]

David Engel writes ("Re: dpkg 1.1.1elf: many changes, more to come"):
...
> I would prefer to have the check in ld.so also.  However, the only way
> I think it could be doen would use a small, uuencoded, ELF binary in
> the preinst script.  Checking in the postinst script would be too
> late.  IMHO, this is too kludgy and not very architecture-indpendent.
> What would a user do if they didn't have uudecode installed or an
> a.out version handy?  The preinst would fail and they couldn't install
> an ELF uudecode until ld.so and libc5 were installed.

I think this is less kludgy than a special package which ld.so
pre-depends on.  Pre-dependencies are best avoided, as they provide
many more points for the installation to break, and creating `stub'
packages whose purpose is to test features seems like a bad idea to me
- users won't understand it.

I think you should use perl's `uudecode string' feature (see the entry
for `pack' in perlfunc) to carry a small `hello world' binary in
whatever architecture is being built for, and probably also (in the
i386 version only, if possibly) check that ELF support isn't a kernel
module.

> I believe it would be best for libc5 to pre-depend on ld.so.  Some
> users might have a very old version of ld.so installed and I'm not
> sure installing both ld.so and libc5 at the same time would do the
> right thing.

Yes, you're right here.  IME you have to upgrad ld.so completely
first.

Ian.