[systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

["Jóhann B. Guðmundsson"]

On 02/04/2015 09:20 PM, Lennart Poettering wrote:
> On Wed, 04.02.15 22:01, Lennart Poettering (lennart at poettering.net) wrote:
>
>> >On Wed, 04.02.15 15:06, Martin Pitt (martin.pitt at ubuntu.com) wrote:
>> >
>>> > >Hey,
>>> > >
>>> > >Lennart Poettering [2015-02-04 13:42 +0100]:
>>>> > > >Well, but their enablement status so far is not ignored. i.e. if you
>>>> > > >drop in a unit file, as well as a sysv script, and the latter is
>>>> > > >enabled, but the former not, then systemd currently reads that so that
>>>> > > >the sysv one is overriden by the native one, and the native one is
>>>> > > >considered enabled.
>>>> > > >
>>>> > > >With this change you alter that behaviour. Is that really desired?
>>> > >
>>> > >Since it's rather confusing what happens in this case, we made
>>> > >systemctl sync the status to update-rc.d (the chkconfig equivalent in
>>> > >Debian) on enable/disable:
>>> > >
>>> > >   http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch
>>> > >
>>> > >That of course doesn't change the behaviour with manual rc?.d/ symlinks.
>>> > >
>>> > >But if you have a native unit, I think it's rather unexpected if you
>>> > >disable it with systemctl, enable it in sysv, but still get it
>>> > >started.
>> >
>> >I'd claim the opposite. Let's say you have foobar.rpm installed in one
>> >version that only carried a sysvinit script. Now you upgrade it to a
>> >version that has a service file. The fact that it was enabled
>> >should not change... Hence, if it is enabled via sysv or via units
>> >doesn't matter really right now...
> Anyway, not too convinced that this is really the better option, but
> not too opposed either. Hence I am OK if something like this goes in.
>

Could not a downstream use a component based preset file hack to 
overcome this?

+ this is extremely limited to Debian and Debian based distribution 
these days and since you don't seem to recall what happened in Fedora 
during the "transaction" period where users had to manually enable 
services ( again ) after the change from the legacy script to unit in 
components during upgrades ( that chkconfig hack FPC came up with, 
approved, implemented and had everybody follow to handle upgrades did 
not work, like many other decision FPC has come up with and made in 
their infinite collective wisdom ).

I expect Debian to do the same sane thing as everyone else did back in 
the day and strike out that components will be allowed to migrate to 
units after beta ( or no later then just before the final release ), so 
end users running the latest stable version of Debian that started with 
an installed sys script wont suddenly find themselves in midst of it's 
release cycle switching to units.

Those doing " release upgrades" can as always expect breakage and or 
manual intervention of some sort so manually enable stuff again is not 
to overcoming and is not a usecase to consider.

Then next thing the Debian community will realize is that once 
maintainers have made the switch to use units they will have to stick 
the legacy sysv initscript in a separated sub component which will 
depend on a virtual provide for all the other init systems ( that is if 
the maintainers want to support those et all ).

The Debian maintainers and or it's leader can already cut corners in 
exhausting decision making and policy handling and just look at how all 
the other distribution ( fedora,opensuse,mageia etc ) handled this and 
have handle this and follow it ( as oppose to re-invent the wheel ) and 
keep all workarounds and hacks to support that transformation and 
multiple init system downstream ( like everyone else had to do ).

JBG