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
change.
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.
--
|8]
Reply to: