Re: systemd .service file conversion
Helmut Grohne wrote:
> On Fri, May 31, 2013 at 01:44:12AM +0300, Uoti Urpala wrote:
> > Steve Langasek wrote:
> > > I can't speak to other distributions, but in Debian, the systemd maintainers
> > > are in no position to decide that Debian will agree to rewrite its
> >
> > Focusing on "position to decide" seems less than constructive.
>
> I believe that you are mistaking Steve's point here. His statement
> appears merely factual to me. And that is what it is. Some of the paths
> you were talking about are explained in the Debian policy as exceptions
> to FHS, and clearly it is not individual maintainers to decide how to
> change the policy.
Individual maintainers are generally not in position to support systemd
in Debian if everyone else opposes, but "you're in no position to
introduce systemd to Debian" would still be less than constructive. I
don't know what you mean by that FHS bit - I don't think anything
under /etc/default is listed as "exception to FHS"?
> > It makes a lot of sense to standardize those files across distributions.
> > You don't seem to disagree with Debian following the FHS for example (or
> > was your attitude to that "our current paths work quite well already,
> > thankyouverymuch" too?). Why would custom /etc file locations be "the
> > very purpose of Debian's existence" in a way that prohibits
> > standardization, if other filesystem layout isn't?
>
> Again you appear to have a difficult time getting the argument. The
> purpose outlined was the integration work, not specific paths. Specific
> paths are merely a tool to get there. They can change, but that requires
> a lot of work and usually breaks tons of stuff. Indeed Debian is
> adopting a number of things from different distributions. That is a hard
> thing to do though, even for things that are already defacto standards.
> For example adopting the required filename encoding from Fedora turned
> out to be harder than expected (#701081). So given the work required to
> change such an aspect, the ones who want the change need pretty good
> arguments.
Nothing in Steve Langasek's message mentioned the amount of work. What
he said was "This integration, which is *the very purpose* of Debian's
existence, is not for systemd upstream (or any upstream) to dictate".
Claiming that he was actually making an argument about how difficult the
change would be to implement seems rather far-fetched. Obviously _you_
want to comment on the implementation aspect, but that's not what I was
replying to earlier, and not something I "failed to get".
The argument for changing is pretty obvious: standardization. I think
you're exaggerating the difficulty of changing for most of those files.
I think discussing the difficulty in more detail would not be meaningful
without considering particular cases. Anyway, my position is that
switching to cross-distro locations used by systemd is desirable; I'm
not saying it would have to be done for every file no matter what the
cost if something is particularly hard in practice. Whereas Langasek was
objecting more generally - he was clearly against such changes even if
easily doable.
> > If you think there is something actually wrong with the default choices
> > currently used by systemd, a much more constructive approach would be to
> > get that fixed across distros, rather than have Debian use a different
> > custom layout. Note that standardizing on the current Debian locations
> > across distros would not have been a good choice for the above two
> > files, as they include the rather arbitrary "/default/" path.
>
> More often than not, there is no wrong with specific naming in
> standards. It just happens that you have to pick one. Indeed systemd
> appears to have come a bit late to the party and Debian has had a
> standard long before. Arguably systemd could be the one opting to adopt
> an existing standard.
I already addressed exactly this point in the text you're replying to:
"Note that standardizing on the current Debian locations across distros
would not have been a good choice for the above two files, ...". There
was good reason to use paths different from the traditional Debian ones
for those two files. Systemd did adopt the Debian location for other
files.
> (Now this is of course false, because RedHat had
> their own file name policy well before the invention of systemd.)
I'm not sure what you were trying to say here (it's unclear what of your
previous text the "false" refers to). Anyway the systemd goal of more
standard paths meant discarding lots of Red Hat-specific paths too, like
things under /etc/sysinit/ (approximately equivalent to Debian
/etc/default/).
> This
> is more true for the socket activation API that systemd could have
> reasonably adopted from upstart, but chose not to do.
Didn't systemd actually have a socket activation API before upstart? I
don't remember exactly, but IIRC upstart at least got it rather late and
there was no standard long before systemd.
> > If you oppose them just because they come from systemd upstream, well...
>
> It appears to me that we are wading into baseless accusations and
> personal attacks. I ask you to just skip such parts next time, because
> they add no value to your arguments.
It's pretty much what he was actually saying - "conform to an arbitrary
rule from systemd upstream", "not for systemd upstream (or any upstream)
to dictate". He gave no arguments why the systemd locations would be
bad, other than that they came from systemd upstream.
> else. Given that systemd is developed at RedHat it appears obvious that
> upstream is biased towards the standards RedHat uses (with a few
> exceptions adopted from Debian and others).
I see little evidence of such "bias" for the standardized configuration.
And anyway IMO such claims should be argued about more specific cases,
rather than say that we should reject standardization in general if in
some specific case systemd upstream did try to adopt a "biased"
standard.
Reply to: