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 don't relish the idea of rebuilding all the base packages again.
> Why is i386-elf-executables-ok necessary?  IMHO, it's silly to keep
> forcing checks like this and 'dpkg --assert-support-predepends' in
> each package's preinst.  These types of checks should be done
> centrally in as few packages as possible with dpkg being the most
> likely candidate followed by ld.so and libc5.  If dpkg aborted when it
> encountered an unknown control file entry instead of quietly ignoring
> it, the problem could be solved by *judiciously* creating new entries.

This problem won't happen again because you can just say `Pre-Depends:
dpkg (>whatever)'; I think that after a while we can remove the checks
for dpkg --assert-support-predepends.

The reason we need i386-elf-executables-ok is because it's a kernel
feature that dpkg can't know about directly.

Here's another idea.  How about (since we say `Pre-Depends: libc5'
anyway) we have the libc5 postinst call or contain
i386-elf-executables-ok or i386-elf-in-kernel.  I think that things
will then themselves out ?

> >    Ones which need a kernel which
> >    boots with ELF support should use /usr/lib/i386-elf-in-kernel
> >    instead.  These scripts will print helpful messages to stderr if
> >    they fail.
> 
> Why do we need to distinguish between ELF support in the kernel or in
> a module?  ELF is the preferred format for the forseeable future.
> We should require it to be in the kernel from the start.

This may make it difficult for people to use the new dpkg, perhaps.  I
think though that if we're doing it by having the check done by libc5
we can forget about the distinction if it's inconvenient.

Ian.