Thomas Goirand <z...@debian.org> writes: > On 05/11/2012 12:53 AM, Uoti Urpala wrote: >> The reason why most old applications do not follow that approach (at >> least not yet) is pretty obvious: their authors never considered it. >> etc-overrides-lib semantics have only become a seriously considered >> alternative fairly recently. >> > No. > > The reason is that we have FHS and the policy, so that packages > *have* to behave the same way, and for very valid reasons which have > been well described in this thread.
Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. The stuff in /lib are package defaults. Where the default is, in the program, embedded, or in some file, doesn't really matter, it's an implementation detail. Overrides (ie, configuration) *is* in /etc, as mandated by policy. > You have absolutely everyone (this includes very experienced DDs) > against your idea of changing a well established Debian policy, well > written in the debian policy manual. Please stop. It's going nowhere. Erm, no. It's not written in the debian policy for a start, and not everyone agrees that etc-overrides-lib is a bad idea. I for one think it's a good idea in selected cases (systemd being one such), and no worse - in some ways, even better - than some other existing practice (the conf.d/ stuff I mentioned a few times elsewhere in this thread already). -- |8] -- 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/87wr4jumk6.fsf@algernon.balabit
