On Fri, Sep 27, 2002 at 03:49:09PM +0200, Santiago Vila wrote: > Several years ago it was agreed that awk would be essential (which > is currently implemented by a "Depends: awk" in base-files). Err, shouldn't base-files Pre-Depends: awk? (In effect, base-files is the "Essential: yes" package that provides the awk functionality (since mawk and gawk *aren't* "Essential: yes"), so it should use a Pre-Depends: to ensure that functionality is available even while base-files is unconfigured. > I was going to propose a patch against the current policy document, > but there is a little problem: > Since dpkg will not prevent upgrading of other packages while an > essential package is in an unconfigured state, all essential packages > must supply all of their core functionality even when unconfigured. If > the package cannot satisfy this requirement it must not be tagged as > essential, and any packages depending on this package must instead > have explicit dependency fields as appropriate. Since awk and gawk aren't tagged "Essential: yes", I'm not sure this really applies. > This paragraph was added to fix Bug#50832 but if we follow it strictly > then all the awk packages are in violation, since they use the > alternative mechanism to update the awk symlink in /usr/awk and > therefore "do not provide their core functionality until they are > configured". Given that a /usr/bin/awk link is made available as part of the initial install, I don't think there's any way of it becoming unavailable even though alternatives are used. > More to the point, I don't see why we should not be able to do the > same with /bin/sh and bash/dash. Suppose bash version X includes /bin/sh in the .deb; bash version Y (> X), doesn't. # dpkg --install bash_Y*.deb foo*.deb bash Y is unpacked over the top of bash X; /bin/sh is removed if present since it's no longer in the package foo's #!/bin/sh preinst script is run, it dies horribly, dpkg aborts I think it's possible to avoid this by having bash Y's preinst dpkg-divert /bin/sh, and make a new symlink that's not controlled by dpkg in preinst, then unpack, then use update-alternatives in postinst. I actually thought that's roughly what bash was doing these days, but apparently not. Using dpkg-divert like that is probably fairly risky -- I'm not sure how it'll cope with the various things people are already doing to /bin/sh -- so you'd want to be fairly thorough working out how every possible case would be handled. > As of today, is it still true that > "dpkg will not prevent upgrading of other packages while an essential > package is in an unconfigured state"? Why should dpkg unconfigure an > essential package to begin with? apt-get will try to avoid it, dpkg won't. dpkg treats "Essential: yes" as "don't let me accidently --remove or --purge it", it's only convention that lets us treat them as "you don't need to specify a dependency on these packages". Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Attachment:
pgpa_8kwB7m2B.pgp
Description: PGP signature