Re: dpkg 1.1.1elf: many changes, more to come
> I noticed shortly after sending it, and sent another copy. I take it
> it's OK for me to send my reply to your reply to debian-devel, too ...
Yes.
> However, I think that the Pre-Depends mechanism is better: the user of
> such a control file field can easily put in a Pre-Depends header,
> which will tell a user or program who reads the Packages file, or a
> user who sees the error from dpkg, exactly which version of dpkg is
> required to install the package.
That should work.
> > I will create a very small package called elf-ok. It will not
> > configure itself unless ELF support is provided in the kernel. I will
> > then build new revisions of ld.so which pre-depends on elf-ok, libc5
> > which pre-depends on the ld.so and base packages which pre-depend on
> > the new libc5.
>
> Is it really necessary to have this awkward small package ? Why not
> just do the test in ld.so, and have libc5 depend (not pre-depend,
> surely ?) on the appropriate version of ld.so ?
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 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.
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: