Support for legacy init script actions for systemd services

Miloslav Trmač mitr at
Tue Jun 26 22:12:47 UTC 2012

On Tue, Jun 26, 2012 at 11:48 PM, "Jóhann B. Guðmundsson"
<johannbg at> wrote:
> On 06/26/2012 08:49 PM, Miloslav Trmač wrote:
>> The preferred new way is that upstream implements the action in a way
>> that is same across all distributions.  Which, in some sense, does not
>> answer your question.
> First and foremost how big of a problem do you guys believe this?
What is "this"?

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

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?

> 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?

> and at the same time a list gets created and populated with the
> relevant packages?
What would be the purpose of such a list?

More information about the devel mailing list