Philip Hands wrote: > 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).
If you walk into a site cold, how do you tell if they have weird local configuration for something? It's much easier to check if there's something under /etc than to start checking whether the files match what's expected for the package version, if the the default files are always there even if nothing has been configured. > 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. And why would this have to be any worse with etc-overrides-lib? > > 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). No, I'm not volunteering, mainly because I don't want to program in shell (which ucf seems to be implemented in). I can still estimate what such an implementation would need to do. You can't argue that everything which has not already been implemented would be a huge fundamental problem. If you want to argue that etc-overrides-lib would be fundamentally bad, hard to support, or undesirable to even try to support in Debian, then you should say more about implementation difficulties than just "it's not implemented at the moment". George Danchev gave a proposed implementation of change alerts in an earlier mail: http://lists.debian.org/<201205110212.30503.danc...@spnet.net> While there are things you'd want to improve in a "real" implementation for packager convenience and better user interface (and the ucf part looks like it'd incorrectly create the file under /etc by default), I think that's enough to demonstrate this is not a particularly hard problem. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1336737949.2227.181.camel@glyph.nonexistent.invalid
