Marco d'Itri wrote: > On May 10, Bjørn Mork <bj...@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"? > 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. > and files > in /lib have no conffiles handling, after an upgrade you will not know > what was changed by you and what was changed upstream. IIRC dpkg does not store the original file (while ucf does), so currently you always lose track of "what was changed by you" unless you make a copy manually (or with extra tools like etckeeper). Anyway, this is about the specifics of what is supported by Debian tools now, not about any intrinsic problem with the behavior. > 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? -- 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/1336674656.2227.72.camel@glyph.nonexistent.invalid
