[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: OpenRC as Init System for Debian



On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
> Marco d'Itri wrote:
> > On May 10, Bjørn Mork <bjorn@mork.no> wrote:
> > 
> > > Agree.  Copying a large set of default policies into /etc just because
> > > they *can* be overridden is not user friendly.  And it does not make the
> > > defaults any more configuration either. It just hides important local
> > > changes and makes it difficult both for the user and the application
> > > itself to distinguish between defaults and configuration overrides.
> 
> > Wrong:
> 
> You're not addressing what he said about the generally desirable /etc
> semantics at all, only talking about what current Debian tools would do
> without modifications. Do you have a reason to oppose beyond "this would
> need some tool changes"?

Yes -- it scatters configuration state outside /etc (thus hiding it from
etckeeper and sysadmins alike), it makes the packages surprising to
people familiar with Debian but not familiar with the package (Hint: we
have a _lot_ of packages -- nobody is familiar with all of
them. Requiring people to become familiar with all the packages before
they can safely do an upgrade is part of what explains the number of
rotting RedHat systems I see than nobody is brave enough to upgrade).

> >  since you have to copy the whole file to override it,
> 
> Wrong: as mentioned in this thread before, one of the advantages of the
> etc-overrides-lib model is the option of having a file in /etc that
> first includes the one in /lib, then overrides just one particular
> value. This allows handling more updates without needing manual changes,
> as you can automatically pick up other updated values while keeping the
> override, without needing to do 3-way merges.

This is the real problem with the etc-overrides-lib approach.  For a
sysadmin to know what to expect from a particular set of configuration
files they need to be intimately familiar with the package in question,
and why the change was made.  Does the package allow partial overrides
with includes or otherwise?  Is the existence of an empty file deeply
significant (think the udev persistent net thing).  Did some default
appear in lib that needs to be carried into etc? etc. etc.

The traditional Debian approach to /etc is largely self documenting, to
the extent that one can generally walk into a site cold and (having
established that they have decent backups) cheerfully do an upgrade on
their Debian servers without anything breaking (I do this regularly).

The sources of potential breakage are highlighted by the packaging
system, at which point you can read up on any package that needs
attention with which you're not already familiar, while ignoring the
ones that upgrade cleanly.

Having exceptions to that is deeply unhelpful, and the more exceptions
we accumulate the less maintainable and upgradable Debian becomes.

Your assert that etc-overrides-lib is technically superior -- I and many
others dispute that, but even if it were true, using that as a
justification is equivalent to pointing out that driving on the left is
safer[1] so Norway should make arrangements to allow visitors from the
UK to drive on the left while the rest of the country continues on the
right.  When it's pointed out that that's a disastrous idea you respond
by saying that all we need to do is fit some clever (as yet unbuilt)
collision avoidance system to all the roads.

> > Obviously this is not a problem for Red Hat since they do not support 
> > upgrades between major releases.
> 
> Why would this cause problems for Debian, except at most needing some
> changes to tools to better support this case? Or do you think
> implementing that would be hard?

Are you volunteering to do that?

If not then stop making assertions that simply require someone else to
do a load of work to pander to your unusual tastes.  If you are
volunteering, then that's somewhat better (although I would prefer
that we simply fix the packages to behave themselves in a proper Debian
way instead).

Cheers, Phil.

[1] see: https://en.wikipedia.org/wiki/Right-_and_left-hand_traffic#Safety_factors
  I believe Japan also did tests -- I don't really care if you disagree,
  just swap Left/Right and UK/Norway throughout the example and relax.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND

Attachment: pgp5Y9hS2TSbv.pgp
Description: PGP signature


Reply to: