Re: RFD: Essential packages, /, and /usr

[Chris Waters <xtifr@debian.org>]

On Mon, Jun 17, 2002 at 10:45:09AM -0500, Steve Greenland wrote:

> Because it's not reliable. At least some portion of it is subject to the
> random whims of the package maintainers (or, far more likely, the random
> whims of bug reporters and a package maintainer who is (understandably)
> unaware that a few of Debian's umpteen thousand packages rely on that
> particular binary being in /bin).

I'm sorry, but if the maintainers of essential packages are unaware of
the fact that those packages are essential, and that major changes in
those packages may have an impact on lots of other packages, then
we're already in deep trouble.

In any case, breakage happens.  I think it's extremely unlikely in
this case, but it happens, and we deal with it.  If such a change were
made, there would be an immediate uproar, thousands of bug reports
would instantly be filed, and the maintainer would face the wrath of
everyone who depends on the old order.  If the maintainer were really
as much of a "blows with the wind" person as you suggest, then any
such change would be almost instantly reverted.

In any case, the number of packages that need to run early in the init
process is probably more in the dozens than the thousands.  Such
extreme hyperbole makes me very suspicious.  Is there some sort of
subtle power play going on here?  If so, I disapprove.  If you have a
problem with the shellutils (or whatever) maintainer, please just say
so, so those of us who are still trying to grasp this issue on
technical terms will understand what's really going on.  From where I
sit, this looks superficially technical, but smells political.
Especially since I haven't seen any good technical arguments from the
supporters of the proposal.

If a change in an essential package were to break dozens (or,
hyperbolically, thousands) of packages, that would be a critical bug!
Forbidding such a change in policy would add nothing to the bug
severity in that case.  And, if such a change were really necessary,
for some reason, then forbidding it in policy would simply mean one
more package that would have to be fixed (i.e. policy itself) to let
such a change go through.  I see no benefit to adding this to policy,
only potential drawbacks.

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku


-- 
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org