Bug#50832: PROPOSED] Clarify meaning of Essential: yes
Anthony Towns <aj@azure.humbug.org.au> writes:
> bash is an Essential: yes package, and recently it was changed so that
> /bin/sh was only there after the postinst was run.
Which closed an RC bug, IIRC. Seems like a damned-if-you-do, damned-
if-you-don't situation.
> + Further, since these packages may be implicitly required by any
> + number of other packages, including dpkg itself, they must function
> + correctly even while unconfigured.
I'm not sure we need this. First, as Wichert pointed out, it may not
always be possible. Furthermore, even when it is possible, it may be
more difficult than it's worth. And finally, since this is the first
time (AFAIK) that a situation like this has come up, it seems like
using a cannon for a flyswatter.
Note that the current situation is already a bug: if things break
because of the way bash is packaged, that's a bug. So we don't really
*need* to modify policy to make this particular case a bug. And if we
modify policy, then we declare cases that *don't* cause problems to be
bugs. With no guarantee that there's any reasonable way to fix these
policy-only bugs.
The bash situation obviously needs to be addressed (and I don't envy
the people who have to satisfy two incompatible sets of demands
there), but I think this proposal is overkill, and I think it may have
unforseen and unpleasant complications. If someone can show that I'm
wrong, then I'll support the proposal, but until then, I object.
(I actually *do* have some ideas on how the bash situation might be
addressed, but they're not relevent to this policy proposal, so I'll
post them somewhere more appropriate.)
cheers
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: