[systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts

"Jóhann B. Guðmundsson" johannbg at gmail.com
Thu May 28 08:10:38 PDT 2015

On 05/27/2015 04:00 PM, Lennart Poettering wrote:
> On Wed, 27.05.15 13:39, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:
>> On 05/27/2015 01:07 PM, Martin Pitt wrote:
>>> Hello,
>>> as discussed in the "get some distro patches upstream" thread, this is
>>> the generalization for supporting different
>>> chkconfig/update-rc.d/whatnot distro implementations of enabling
>>> init.d scripts, as per LSB specification.
>> Is this not something that downstream should be carrying tailored to what
>> init implementation what was used in the past and or is shipped in the
>> present, ( Debian for example ships/supports multiple init systems ) and the
>> support for this dropped upstream?
> Well, I think it's too early for that. 3rd party software tends to be
> written for LSB. Also, Debian/Ubuntu only very recently switched to
> sytemd. Out of fairness we owe them to support the old stuff natively
> for a while, the same way we benefitted from that during the fedora
> transition.

Last time I checked Debian shipped the most initscripts of the 
distributions roughly half more then we do in Fedora ( ca 1200 components ).

Now if we put aside Debians support for multiple initsystem which makes 
it more likely that they prefer using generators instead of actually 
migrate components and we subtract the collaborated migration effort 
done by us systemd integrators that resided in distributions community 
that we did together for what past 4 or five years, it will leave ca 600 
components for Debian to migrate and they will do so in roughly the same 
time frame as we all did collectively I would expect.

Add to that the "long discussion, approval period" in Debian's community 
before that work would actually start to happen, we are talking about 
supporting this for 5 - 7 years more ( unless something is done here , 
upstream to nudge it's completion sooner ).

3rd party software will not migrate until they have to that is a fact ( 
and distributions and upstream cannot wait for something they have 
absolutely no control over which is another fact ).

> Also, there are still ~100 sysv scripts in fedora too...

I'm perfectly aware the status on unmigrated components along with other 
systemd integration and cleanup work has not progressed since I stopped 
leading and doing that in Fedora and now that has started to hinder 
other work ( as I had expected would happen ) but this is what some of 
your coworkers wanted and this is precisely what they got with the 
associated cost of their behavior and decision(s) which ultimately will 
cost Red Hat more in work,money and delays of it's upcoming RHEL release(s)

There was an FESCo discussion dropping all the 100 - 150 components that 
had not been migrated in F23 with Adam Jackson valiantly assigning an 
task to himself and trying migrated what he could up to that point ( 
kudos to him for that. I have not seen that spirit in FESCo member since 
what FC5/6 ) I just dont think he realized how much amount of work that 
was nor how distracting it would become from his other work/upstream 
obligations not that I have checked but I expect that he has abandoned 
that work by now or it's progressing very very slowly.


More information about the systemd-devel mailing list