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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
