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:
pgpEnl8zGKLA7.pgp
Description: PGP signature