[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: OpenRC as Init System for Debian



[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).


Reply to: