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

Re: RFC: OpenRC as Init System for Debian

Tollef Fog Heen <tfheen@err.no> writes:

> ]] Gergely Nagy 
>> Tollef Fog Heen <tfheen@err.no> writes:
>> > ]] Uoti Urpala 
>> >
>> > Hi,
>> >
>> >> 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.
>> >
>> > This doesn't always work, though.  For instance, for systemd, you'd have
>> > no way to get rid of an ExecStartPre line, since you can have multiple
>> > of them.  It's probably not that common, but it's a use case I want to
>> > support.
>> In that case, the including file can be changed (by the admin) to be a
>> separate file, that does not include, and get the usual conffile
>> conflict dpkg prompt.
> How would that work?
> I have /lib/systemd/system/foo.service and want to change something in
> it, I then create /etc/systemd/system/foo.service with a copy of the
> /lib one plus whatever changes I want.
> The version in /lib is then updated.  How is the admin notified?

NEWS.Debian, like with any significant default change.

Other than that, the best I can think of is keeping track of what
version of the package a default changed in, and triggering something
from preinst, when upgrading from a version that is older than the

This however, requires a lot of manual work, might aswell shovel the
whole thing from under /lib to /etc then, but then we still didn't solve
the problem: suppose there is a unit file that supports starting
multiple instances, by way of symlinking. I start to use this feature,
I change nothing, just symlink files around. At some point, this feature
gets removed, my upgrade succeeds, but my instances won't start anymore,
and the best notification I have is something that scrolled by that a
conffile was upgraded.

In this case, we have a succesful upgrade resulting in a broken system,
because a default changed, and the user was not adequately notified.

Which gets us back to NEWS.Debian being the best solution. There simply
are cases where no automatism can be clever enough.


Reply to: