Re: Essentialness of awk
Anthony Towns wrote:
> 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.
Actually, base-files does not provide the functionality of awk.
The different awk packages do (see the Provides: awk :-).
What we currently do to ensure that their functionality is always
available is to make them to predepend on their shared libraries,
as every essential package do, since any of the awk packages may
have the role of being an essential package.
base-files just ensures that some awk is always available and for this
purpose a depends seems to be enough, unless we do not consider as a
bug that dpkg fails to satisfy a dependency from an essential package
during an upgrade, that is.
> > 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.
None of them are essential by itself, but if you have only one of them
installed in the system, then it should behave as if it were essential.
That's why we apply the predepends rule to the awk packages.
> > 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.
Exactly, but still none of the awk packages will work when unconfigured
(before they are bootstrapped), as policy seems to forbid.
> > 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
Indeed, but bash version Y (>X) which does not provide /bin/sh in the .deb
is, in some way, a step backwards as far as bootstrapping is concerned.
> 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.
What I find most interesting about this is that this is only a problem
if we want to switch from the current status to an alternatives-managed
/bin/sh symlink. It seems if we had used the alternatives thing for
/bin/sh from the beginning of times we would not have any problem.
Reply to: