[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.
JBG
More information about the systemd-devel
mailing list