Support for legacy init script actions for systemd services
"Jóhann B. Guðmundsson"
johannbg at gmail.com
Tue Jun 26 23:24:52 UTC 2012
On 06/26/2012 10:12 PM, Miloslav Trmač wrote:
> What is "this"?
Sorry meant to say "this is"
There are maybe a handful of services that need this hence the
precaution clause so packagers/maintainers simply don't choose to do
exactly what Bill was referring to in "3)"
>
> Breaking "service foo action" reason was just an unnecessary
> regression that shouldn't have happened in the first place. But given
> the history and the length of time that has passed, I'd say that
> whether to restore this functionality now is up to individual package
> maintainers.
Agreed and honestly this sudden turnaround now smells a bit like RHEL
"7" was a big contributing factor to that decision since this has been a
know problem from the start..
>
> Asking upstreams to "adopt" things that used to be done in
> distributions (and therefore were consistent within a distribution)
> without suggesting a good convention to follow (suggesting a high
> probability that they will not be consistent, and distributions will
> not be "allowed" to make them consistent) sounds like a change for the
> worse from the original state (it is, after all, one of the primary
> roles of a distribution to collect various differing upstreams and
> make a consistent OS from them) - but, well, the result will not be
> different from any other inter-project inconsistencies, so I don't
> view this as a "problem". To the extent that systemd initiated this
> change, perhaps the convention should be suggested somewhere within
> the systemd project, ideally with input from distributions?
I would rather argue that various upstreams should reach agreement on
how things should properly be done and moved forward and distribution
downstream to the relevant upstream should adopt that rather then the
other way around since the likely hood of that input you refer they
should do will actually never make it out of the distribution due to
distribution politics .
The /etc/sysconfig/foo and /etc/default/bar file problem which is
explained in a bit more detail here [1] is perfect example on how
distributions will never manage to agree amongst themselves to propose
or provide input *together* because more often then not each
distribution has a tendency to think that their way is the *right* way.
I should mentioned in relevance to the above example that I have yet to
find an upstream maintainer that disagrees with the elimination of that
difference between distributions and that elimination will never come to
be until we stop exercise that administrators muscle memory Bill was
referring to.
I'm pretty sure that this administrators muscle memory which has been
referred to no longer exist amongst the administrators in the Fedora
project since we have had the initial release that systemd got accepted
in gone EOL and just for the Lennart haters that exist out there I
should mention that *every* bug got addressed and fixed by the systemd
team during F15 lifecycle.
>
>> >Secondly cant we add the rule that packager are required to request
>> >permission from fesco to follow what is suggested before they implement it
>> >so it can be ensured that it's actually required/necessary for them to do
>> >this
> Is there any reason to forbid any implementation that follows the best
> practices above? And a reason to require special dispensation instead
> of relying on the regular review process?
My concern are exactly the same as Bill mentions in item three on his list.
>
>> >and at the same time a list gets created and populated with the
>> >relevant packages?
> What would be the purpose of such a list?
Informative
JBG
1. http://0pointer.de/blog/projects/on-etc-sysinit.html
More information about the devel
mailing list