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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130531061654.ga29...@alf.mars
