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 <[EMAIL PROTECTED]> <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: pgpPkXgP60QdC.pgp
Description: PGP signature

Reply via email to