[Uoti Urpala]
> 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.
If I'm not mistaken, I first saw this sort of arrangement in CDE, circa
1998. Maybe that's considered "recent". Sure, nobody's heard of it
anymore, but it was pretty widespread back in the day.
There were a lot of things I didn't like about CDE, and this was one of
them.
> From your following text it seems you mean the comparison between 1)
> criticizing Red Hat for (allegedly) letting packaging system
> limitations affect the choice of configuration format and 2) saying
> Debian should choose its preferred configuration format based on the
> limitations of its packaging system
That's ... a misleading way of looking at it. There is a tension
between minor upgrades and major upgrades.
1. Major upgrades: default config may change noticeably, and a custom
config forked from the default may need to be updated to work
optimally or even correctly.
- Red Hat apparently has no reason to care about this case, if they
don't support major upgrades at all.
- This is where "copy to /etc" can be bad. It's not trivial for
the packaging to determine that the local copy needs attention,
either to handle it automatically, or to alert the local admin.
2. Minor upgrades, or reinstall: default config rarely changes, and
does not change incompatibly. E.g., a security upload.
- Red Hat _does_ need to support this case.
- This is where "copy to /etc" works. It prevents the packaging
system from overwriting your local config changes.
- Apparently RPM packaging and tooling has a history of overwriting
local config changes. I don't know the details. But if true,
"copy to /etc" would seem like an attractive workaround.
- However, Debian's packaging has had policy and tooling to avoid
overwriting local changes for about 20 years, so it should not be
surprising that we don't see much upside here, only the downside
(mentioned in point 1).
--
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/20120510190217.gc2...@p12n.org
