Re: systemd .service file conversion
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.
> 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.
> 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. (Now this is of course false, because RedHat had
their own file name policy well before the invention of systemd.) This
is more true for the socket activation API that systemd could have
reasonably adopted from upstart, but chose not to do.
> 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.
> Of course Debian can choose to use different locations/semantics for the
> files if there is some actual justification. But IMO it's completely
> reasonable for upstream to decide that they should not be the ones who
> bear the burden of maintaining the patches for any such distro-specific
> divergences.
systemd is a project that claims to do integration work. It clearly has
a big surface of interfaces with other projects. Otherwise it would not
be discussed that often and would be easily swappable for something
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). The incompatible socket
activation API is a prime example for this. So in this case I think
there is less reason to trust this particular upstream with our needs.
On the other hand I see little point in discussing this further, because
the Debian systemd maintainers are doing an awesome job.
Helmut
Reply to: