Re: RFC: OpenRC as Init System for Debian
Tollef Fog Heen <tfheen@err.no> writes:
> ]] Gergely Nagy
>
>> Tollef Fog Heen <tfheen@err.no> writes:
>>
>> > ]] Gergely Nagy
>
>> >> 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.
>
> So you won't get the dpkg conffile conflict prompt, then? Can you
> explain what the scenario you talked about would look like, since it's
> apparently not the scenario I was thinking about?
I believe we're talking about the same scenario, and I was hasty to
suggest that NEWS.Debian is the only way - see below.
>> 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 is basically what the tool I'm suggesting to write will do.
During my trip back home, I wrote that tool. It's very crude and hackish
at the moment, but with a little bit of support from, say, apt (or
perhaps dpkg, but that's less likely), it could be made into something
nice.
Basically, I divert dpkg, and catch all -i calls, see what debs we're
called on, list the files therein. If any of the files are on the
watchlist, I launch the triggers, with apropriate parameters. The only
trigger I have implemented so far will extract the files that triggered
it, and put them in version control, onto the appropriate upstream
branch. Then proceed on.
I could enhance it to abort the installation, or send mail, or pause and
do some ucf magic, to check whether overrides in /etc exist at all, and
so on and so forth.
I only needed the shovel-into-a-vcs-branch thing, so that's what I
have. Adding the rest isn't hard, either.
The advantage here, is that the packager need not keep track of what
changed in which version, and admins can extend the watchlist, and
change the triggered actions too, to make it better suit their own
needs. This also means that in case of bugs, we don't need to fix
maintainer scripts, just a single application.
--
|8]
Reply to: