I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3].
Seriously, please don't do this.
Nathaniel
1 - http://nathaniel.themccallums.org/2012/01/28/systemd-rocks-my-world/ 2 - https://bugzilla.redhat.com/show_bug.cgi?id=791229 3 - https://bugzilla.redhat.com/show_bug.cgi?id=794777
On Fri, Feb 17, 2012 at 10:46:58AM -0500, Nathaniel McCallum wrote:
I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3].
Seriously, please don't do this.
Nathaniel
1 - http://nathaniel.themccallums.org/2012/01/28/systemd-rocks-my-world/ 2 - https://bugzilla.redhat.com/show_bug.cgi?id=791229 3 - https://bugzilla.redhat.com/show_bug.cgi?id=794777
Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18).
Which are you advocating?
-Toshio
On Fri, Feb 17, 2012 at 11:48 AM, Toshio Kuratomi a.badger@gmail.comwrote:
On Fri, Feb 17, 2012 at 10:46:58AM -0500, Nathaniel McCallum wrote:
I'm a fan of systemd [1]. And although I didn't like the fact that unit
files
were stored in /lib, I understood the rationale since there was no
/share.
However, I've just recently discovered [2] that after UsrMove unit files
will
be stored in /usr/lib. Can we not do better than this? And I'd really
rather
not work around the problem [3].
Seriously, please don't do this.
Nathaniel
1 - http://nathaniel.themccallums.org/2012/01/28/systemd-rocks-my-world/ 2 - https://bugzilla.redhat.com/show_bug.cgi?id=791229 3 - https://bugzilla.redhat.com/show_bug.cgi?id=794777
Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18).
Which are you advocating?
Move systemd unit files to /usr/share and provide simple logic to fall back /lib, so as not to break upgrades with custom unit files. I am certainly not advocating a bad user experience. If the schedule doesn't permit it, I'm ok with delaying the move to /usr/share until f18. However, I would want to avoid two moves at all costs. I can't imagine moving them to /usr/shared is a huge task (considering any bugs you would hit would likely already be hit by UsrMove anyway) or that moving the unit files from /lib to /usr/share is any different than moving them from /lib to /usr/lib. So the upgrade experience can't be really harmed by such a move.
Nathaniel
Am 17.02.2012 18:00, schrieb Nathaniel McCallum:
Move systemd unit files to /usr/share and provide simple logic to fall back /lib, so as not to break upgrades with custom unit files. I am certainly not advocating a bad user experience. If the schedule doesn't permit it, I'm ok with delaying the move to /usr/share until f18. However, I would want to avoid two moves at all costs. I can't imagine moving them to /usr/shared is a huge task (considering any bugs you would hit would likely already be hit by UsrMove anyway) or that moving the unit files from /lib to /usr/share is any different than moving them from /lib to /usr/lib. So the upgrade experience can't be really harmed by such a move.
you are missing the point that /lib/ to /usr/lib is a theoretical not invasive change by replacing /lib with a symlink!
moving things around the filesystem means you are breaking each sort of scripts and whatever customized software is runnign at the users machines - can we please stop to enforce permanently chaning paths all over the world for some beautniess reason without any technical point for it
On Fri, Feb 17, 2012 at 12:04 PM, Reindl Harald h.reindl@thelounge.netwrote:
Am 17.02.2012 18:00, schrieb Nathaniel McCallum:
Move systemd unit files to /usr/share and provide simple logic to fall
back /lib, so as not to break upgrades with
custom unit files. I am certainly not advocating a bad user experience.
If the schedule doesn't permit it, I'm ok
with delaying the move to /usr/share until f18. However, I would want to
avoid two moves at all costs. I can't
imagine moving them to /usr/shared is a huge task (considering any bugs
you would hit would likely already be hit
by UsrMove anyway) or that moving the unit files from /lib to /usr/share
is any different than moving them from
/lib to /usr/lib. So the upgrade experience can't be really harmed by
such a move.
you are missing the point that /lib/ to /usr/lib is a theoretical not invasive change by replacing /lib with a symlink!
I'm fine if you want to symlink /usr/lib/systemd/system to /usr/share/systemd/system or something else comparable. That should be just as noninvasive. My point is that custom files installed in /lib already have to be moved to /usr/lib. Why not also cleanly move systemd unit files to a more standard location?
moving things around the filesystem means you are breaking each sort of scripts and whatever customized software is runnign at the users machines - can we please stop to enforce permanently chaning paths all over the world for some beautniess reason without any technical point for it
Well, we've already decided to do these kinds of changes (aka UsrMove). If we are going to do so, why not do it right? Besides, we already have nice mechanisms like pkg-config variables to find the right paths for things, your scripts should use those. And what script is going to break by the move to /usr/share that won't be broken by the move to /usr/lib when the proper symlinks are in place?
Nathaniel
Am 17.02.2012 18:16, schrieb Nathaniel McCallum:
On Fri, Feb 17, 2012 at 12:04 PM, Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net> wrote:
Am 17.02.2012 18:00, schrieb Nathaniel McCallum: > Move systemd unit files to /usr/share and provide simple logic to fall back /lib, so as not to break upgrades with > custom unit files. I am certainly not advocating a bad user experience. If the schedule doesn't permit it, I'm ok > with delaying the move to /usr/share until f18. However, I would want to avoid two moves at all costs. I can't > imagine moving them to /usr/shared is a huge task (considering any bugs you would hit would likely already be hit > by UsrMove anyway) or that moving the unit files from /lib to /usr/share is any different than moving them from > /lib to /usr/lib. So the upgrade experience can't be really harmed by such a move. you are missing the point that /lib/ to /usr/lib is a theoretical not invasive change by replacing /lib with a symlink!
I'm fine if you want to symlink /usr/lib/systemd/system to /usr/share/systemd/system or something else comparable. That should be just as noninvasive. My point is that custom files installed in /lib already have to be moved to /usr/lib. Why not also cleanly move systemd unit files to a more standard location?
currently /lib will be linked to /usr/lib
what you are proposing is braindead moving around things and replace all of them by more and more symlinks all over the system
for what reason? fun to do changes? why are you not starting to develop a software on your own if you are borded and leave people which are happy with working systems in peace?
On 02/17/2012 04:48 PM, Toshio Kuratomi wrote:
Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18).
Which are you advocating?
If you are going to move units to /usr/share I suspect you want to move the rest as well udev, modprobe, depmod, tmpfiles, modules-load etc...
JBG
2012/2/17 "Jóhann B. Guðmundsson" johannbg@gmail.com
On 02/17/2012 04:48 PM, Toshio Kuratomi wrote:
Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18).
Which are you advocating?
If you are going to move units to /usr/share I suspect you want to move the rest as well udev, modprobe, depmod, tmpfiles, modules-load etc...
Sure, as time permits and when such can be done without harming user experience.
On 02/17/2012 05:09 PM, Nathaniel McCallum wrote:
Sure, as time permits and when such can be done without harming user experience.
Why bother only with unit files? Users never touch those the ones in /lib/systemd/system or /usr/lib/systemd/system anyway so there is no breakage for them...
JBG
On Fri, 2012-02-17 at 17:17 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/17/2012 05:09 PM, Nathaniel McCallum wrote:
Sure, as time permits and when such can be done without harming user experience.
Why bother only with unit files? Users never touch those the ones in /lib/systemd/system or /usr/lib/systemd/system anyway so there is no breakage for them...
Well, as we discussed the other day on IRC, we pretty much all agreed that it's not in the spirit of the FHS to have these files in /lib or /usr/lib. The only reason they were ever in /lib to begin with is because /share didn't exist (and at the time we were (correctly) positioning systemd as being prefix=/ and not prefix=/usr).
On 2012-02-17 10:28, Stephen Gallagher wrote:
On Fri, 2012-02-17 at 17:17 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/17/2012 05:09 PM, Nathaniel McCallum wrote:
Sure, as time permits and when such can be done without harming
user
experience.
Why bother only with unit files? Users never touch those the ones in /lib/systemd/system or /usr/lib/systemd/system anyway so there is no breakage for them...
Well, as we discussed the other day on IRC, we pretty much all agreed that it's not in the spirit of the FHS to have these files in /lib or /usr/lib. The only reason they were ever in /lib to begin with is because /share didn't exist (and at the time we were (correctly) positioning systemd as being prefix=/ and not prefix=/usr).
That wasn't the impression I got. Some people at least seemed to be arguing that /usr/share was no more 'correct' for systemd unit files than /usr/lib/systemd is.
Le Ven 17 février 2012 18:40, Adam Williamson a écrit :
On 2012-02-17 10:28, Stephen Gallagher wrote:
Well, as we discussed the other day on IRC, we pretty much all agreed that it's not in the spirit of the FHS to have these files in /lib or /usr/lib. The only reason they were ever in /lib to begin with is because /share didn't exist (and at the time we were (correctly) positioning systemd as being prefix=/ and not prefix=/usr).
That wasn't the impression I got. Some people at least seemed to be arguing that /usr/share was no more 'correct' for systemd unit files than /usr/lib/systemd is.
Trying to distinguish between code and data is a lost cause. arch independant vs arch dependant is a clean simple boundary and the one fedora has historically supported (look where lisp or java code is today)
Am 17.02.2012 18:09, schrieb Nathaniel McCallum:
2012/2/17 "Jóhann B. Guðmundsson" <johannbg@gmail.com mailto:johannbg@gmail.com>
On 02/17/2012 04:48 PM, Toshio Kuratomi wrote: Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18). Which are you advocating? If you are going to move units to /usr/share I suspect you want to move the rest as well udev, modprobe, depmod, tmpfiles, modules-load etc...
Sure, as time permits and when such can be done without harming user experience.
FOR WHAT REASON?
such changes do ALWAYS harming user experience
why? becaus eoperating systems are (or where it seems) made to give users the base for their own work, scripts, automatisms and the idea of linux once was give users a CUSTOMIZEABLE system
by permanently change thins for the sake of the change you are killing the "customizeable" becasue it is better not do this at all to be safe for useless changes made from bored people upstream your OS
PLEASE STOP THIS BAD ATTITUDE DAMAGE PERMANENTLY CUSTOMIZED SYSTEMS JUST FOR FUN OR YOU WILL NEVER IN THIS LIFE HAVE USERS USING LINUX IF THEY WANT TO DO MORE THAN INSERT A DVD AND EAT WHAT SOMEONE OTHER DECIDED IS GOOD FOR THEM
On Fri, Feb 17, 2012 at 12:17 PM, Reindl Harald h.reindl@thelounge.netwrote:
Am 17.02.2012 18:09, schrieb Nathaniel McCallum:
2012/2/17 "Jóhann B. Guðmundsson" <johannbg@gmail.com <mailto:
johannbg@gmail.com>>
On 02/17/2012 04:48 PM, Toshio Kuratomi wrote: Yeah -- so I see three options -- move systemd unit files to
/usr/share,
revert /usr/move, change rpmlint (or a fourth -- ignore this
warning for f17
and move systemd unit files to /usr/share for f18). Which are you advocating? If you are going to move units to /usr/share I suspect you want to
move the rest as well udev, modprobe,
depmod, tmpfiles, modules-load etc...
Sure, as time permits and when such can be done without harming user
experience.
FOR WHAT REASON?
such changes do ALWAYS harming user experience
why? becaus eoperating systems are (or where it seems) made to give users the base for their own work, scripts, automatisms and the idea of linux once was give users a CUSTOMIZEABLE system
by permanently change thins for the sake of the change you are killing the "customizeable" becasue it is better not do this at all to be safe for useless changes made from bored people upstream your OS
PLEASE STOP THIS BAD ATTITUDE DAMAGE PERMANENTLY CUSTOMIZED SYSTEMS JUST FOR FUN OR YOU WILL NEVER IN THIS LIFE HAVE USERS USING LINUX IF THEY WANT TO DO MORE THAN INSERT A DVD AND EAT WHAT SOMEONE OTHER DECIDED IS GOOD FOR THEM
So we should never change anything, right? Tone down the rhetoric please. I'm asking for gradual evolution here without pain.
Am 17.02.2012 18:20, schrieb Nathaniel McCallum:
> Sure, as time permits and when such can be done without harming user experience. FOR WHAT REASON? such changes do ALWAYS harming user experience why? becaus eoperating systems are (or where it seems) made to give users the base for their own work, scripts, automatisms and the idea of linux once was give users a CUSTOMIZEABLE system by permanently change thins for the sake of the change you are killing the "customizeable" becasue it is better not do this at all to be safe for useless changes made from bored people upstream your OS PLEASE STOP THIS BAD ATTITUDE DAMAGE PERMANENTLY CUSTOMIZED SYSTEMS JUST FOR FUN OR YOU WILL NEVER IN THIS LIFE HAVE USERS USING LINUX IF THEY WANT TO DO MORE THAN INSERT A DVD AND EAT WHAT SOMEONE OTHER DECIDED IS GOOD FOR THEM
So we should never change anything, right? Tone down the rhetoric please. I'm asking for gradual evolution here without pain.
i do NOT TONE DOWN you are asking for changes nobody needs
where did i say "never change anything" i said "do not things that are ain't broken"
if you are bored searh for work but not for changeing things working to produce all sort of bugs over the long which are giving you work again by try to fix them
where does /lib/systemd hurt you? where does most other locations currently used hurt you? why are they hurting you? are they hurting you so bad that you do not find any useful work to do instead proposing changes for the sake of the change?
i am one of the idiots who have to deal with useless chnages stealing me the time to make useful ones in software dveloped by me - so what do you think which sort of answer yiu get propose stealing more and more of my time for NOTHING?
On Fri, Feb 17, 2012 at 06:25:23PM +0100, Reindl Harald wrote:
Am 17.02.2012 18:20, schrieb Nathaniel McCallum:
> Sure, as time permits and when such can be done without harming user experience. FOR WHAT REASON? such changes do ALWAYS harming user experience why? becaus eoperating systems are (or where it seems) made to give users the base for their own work, scripts, automatisms and the idea of linux once was give users a CUSTOMIZEABLE system by permanently change thins for the sake of the change you are killing the "customizeable" becasue it is better not do this at all to be safe for useless changes made from bored people upstream your OS PLEASE STOP THIS BAD ATTITUDE DAMAGE PERMANENTLY CUSTOMIZED SYSTEMS JUST FOR FUN OR YOU WILL NEVER IN THIS LIFE HAVE USERS USING LINUX IF THEY WANT TO DO MORE THAN INSERT A DVD AND EAT WHAT SOMEONE OTHER DECIDED IS GOOD FOR THEM
So we should never change anything, right? Tone down the rhetoric please. I'm asking for gradual evolution here without pain.
i do NOT TONE DOWN
You really should.
you are asking for changes nobody needs
Because, while there are relevant objections to features being presented, the manner in which you present them means that people want to dismiss them. In fact, your tone has become so over the top that people have gone from wanting to dismiss to actually dismissing them.
Unless you are trying to use reverse psychology, this is serving nobody's interests.
-Toshio
Le Ven 17 février 2012 18:02, "Jóhann B. Guðmundsson" a écrit :
On 02/17/2012 04:48 PM, Toshio Kuratomi wrote:
Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18).
Which are you advocating?
If you are going to move units to /usr/share I suspect you want to move the rest as well udev, modprobe, depmod, tmpfiles, modules-load etc...
That would be a worthwhile cleanup and make startup services behave like normal apps at last (and usermove ils all about cleaning up historical FHS peculiarities)
On Fri, 17.02.12 10:46, Nathaniel McCallum (nathaniel@natemccallum.com) wrote:
I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3].
Seriously, please don't do this.
The unit files are in /lib for a couple of reasons. Firstly, before the /usr merge there was no /share, so we had to place them in /lib. Secondly I think that /lib is actually the better fit for them, simply because I consider them closely related to the code they wrap, and code belongs in lib, libexec or bin. How does that matter? Well, the unit files are very often dependendent on/closely related to the architecture, and make little sense to share them between archs. This applies to a couple of units we ship with systemd itself (for example the hugepages mount unit), but even more often to unit we don't ship ourselves (think mcelog). And distributing these unit files among a number of dirs would seriously suck.
We need to retain compatibility for the directory from before the /usr merge and I think lib/ is actually a better place for this than share/, hence I think I see little reason to move this.
/share is a great place for truly arch independent data that is shared between multiple applications, and which is read by multiple applications (such as icons, man pages, dictionaries and suchlike). But for stuff that is very close to specific bits of code, and is only read by a single tool /lib is the much better place I think. A good way to think about this is maybe "if I remove something in /lib it seriously impacts the control flow of code" vs. "if I remove something in /share it hast little impact on control flow".
Something similar applies to udev rules and similar "almost code" bits.
But yeah, I know people will disagree with us on this. Maybe a different way to think about this is to think about shell scripts. We ship those in /bin, and not in /share either. And it is good that way. And if that still doesn't convince you, then I hope at least the "keep compat" issue pointed out above matters enough to you.
So, no plans to move the unit files to /usr/share. Sorry.
Lennart
Le Lun 20 février 2012 13:02, Lennart Poettering a écrit :
Something similar applies to udev rules and similar "almost code" bits.
But yeah, I know people will disagree with us on this.
Lennart , you realise, do you, that people are unlikely to fix the historical exceptions they've benefited from as part of systemd or usrmove if you're championing the creation of new exceptions for your own sake in parallel.
Systemd unit files are no more cody and app-specific (and in fact quite a lot less) than emacs lisp files or java jar files or docbook xslt processing rules or a lot more stuff I'm forgetting about right now and those have been in /usr/share for a *long* time.
On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mailhot@laposte.net) wrote:
Le Lun 20 février 2012 13:02, Lennart Poettering a écrit :
Something similar applies to udev rules and similar "almost code" bits.
But yeah, I know people will disagree with us on this.
Lennart , you realise, do you, that people are unlikely to fix the historical exceptions they've benefited from as part of systemd or usrmove if you're championing the creation of new exceptions for your own sake in parallel.
This isn't really a "new" exception for me. There's a ton of files that are not strictly arch dependent in bin, lib, libexec. Shell scripts, Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB symlinks, Java files, Ruby files, yadda yadda yadda.
The thing is simply that there are cases where things are clear that they belong on /lib, and others where it is clear that they belong in /share. And then there is this huge grey area in the middle of those files where things aren't super clear. The line between /lib and /share is blurry. And since about always people then ended up coming to different conclusions and hence dropped some stuff that you don't think belongs in /lib into that very dir, and some stuff that others don't think belongs in /share into that very dir.
I think a rule of "if in doubt, /lib is preferable" is the safe choice here though. In the case for unit files we have a couple of good reasons to consider them arch-specific enough beyond just mere "if in doubt". (see my earlier mail for them).
Systemd unit files are no more cody and app-specific (and in fact quite a lot less) than emacs lisp files or java jar files or docbook xslt processing rules or a lot more stuff I'm forgetting about right now and those have been in /usr/share for a *long* time.
I see a ton of jar files in /usr/lib here actually.
The world isn't black and white. The separation between /share and /lib is more complex than simple binary logic.
Lennart
Dne 20.2.2012 13:51, Lennart Poettering napsal(a):
On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mailhot@laposte.net) wrote:
Le Lun 20 février 2012 13:02, Lennart Poettering a écrit :
Something similar applies to udev rules and similar "almost code" bits.
But yeah, I know people will disagree with us on this.
Lennart , you realise, do you, that people are unlikely to fix the historical exceptions they've benefited from as part of systemd or usrmove if you're championing the creation of new exceptions for your own sake in parallel.
This isn't really a "new" exception for me. There's a ton of files that are not strictly arch dependent in bin, lib, libexec. Shell scripts, Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB symlinks, Java files, Ruby files, yadda yadda yadda.
No more for Ruby ...
Vit
On Mon, Feb 20, 2012 at 13:51, Lennart Poettering mzerqung@0pointer.de wrote:
On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mailhot@laposte.net) wrote:
Le Lun 20 février 2012 13:02, Lennart Poettering a écrit :
Something similar applies to udev rules and similar "almost code" bits.
But yeah, I know people will disagree with us on this.
Lennart , you realise, do you, that people are unlikely to fix the historical exceptions they've benefited from as part of systemd or usrmove if you're championing the creation of new exceptions for your own sake in parallel.
It's not a new exception, it's the reality for udev since ~6 years.
This isn't really a "new" exception for me. There's a ton of files that are not strictly arch dependent in bin, lib, libexec. Shell scripts, Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB symlinks, Java files, Ruby files, yadda yadda yadda.
The thing is simply that there are cases where things are clear that they belong on /lib, and others where it is clear that they belong in /share. And then there is this huge grey area in the middle of those files where things aren't super clear. The line between /lib and /share is blurry. And since about always people then ended up coming to different conclusions and hence dropped some stuff that you don't think belongs in /lib into that very dir, and some stuff that others don't think belongs in /share into that very dir.
I think a rule of "if in doubt, /lib is preferable" is the safe choice here though. In the case for unit files we have a couple of good reasons to consider them arch-specific enough beyond just mere "if in doubt". (see my earlier mail for them).
I second that.
Systemd unit files are no more cody and app-specific (and in fact quite a lot less) than emacs lisp files or java jar files or docbook xslt processing rules or a lot more stuff I'm forgetting about right now and those have been in /usr/share for a *long* time.
I see a ton of jar files in /usr/lib here actually.
The world isn't black and white. The separation between /share and /lib is more complex than simple binary logic.
That sounds right. And for the same reason, the udev rules need to stay in lib/ and not move to share/.
Udev rules are not meant to be *shared* across anything, not across different machines, not across architectures, not across multiple packages. They only get installed _for_ the udev version that is the primary architecture, and there can only be one udev version installed on a system. The rules get installed by multiple packages, sure; but they do not involve any, and must actually prevent any sort of *sharing*.
The very same that is true for udev, is true for sytemd units. Rules and units do not provide any additional or optional data, they influence the actual global system runtime behaviour, they change and extend the system, very much like a service plugin or a shared object.
That they are actually text file, is an implementation detail that should not have influence on the installation directory.
Thanks, Kay
On Mon, 2012-02-20 at 13:51 +0100, Lennart Poettering wrote:
This isn't really a "new" exception for me. There's a ton of files that are not strictly arch dependent in bin, lib, libexec. Shell scripts, Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB symlinks, Java files, Ruby files, yadda yadda yadda.
Not that it matters much, but just before somebody gets the wrong ideas: pkg-config files are arch-dependent because of multilib.
Nils
Le Lun 20 février 2012 18:18, Nils Philippsen a écrit :
On Mon, 2012-02-20 at 13:51 +0100, Lennart Poettering wrote:
This isn't really a "new" exception for me. There's a ton of files that are not strictly arch dependent in bin, lib, libexec. Shell scripts, Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB symlinks, Java files, Ruby files, yadda yadda yadda.
Not that it matters much, but just before somebody gets the wrong ideas: pkg-config files are arch-dependent because of multilib.
and the java files are there either because they use jni (so not arch-independant) or are remnants of the time gcj was use to native-compile them (and gcj was dropped before it learnt not to require that .jars and generated native code be in the same dir)
On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
On Fri, 17.02.12 10:46, Nathaniel McCallum (nathaniel@natemccallum.com) wrote:
I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3].
Seriously, please don't do this.
The unit files are in /lib for a couple of reasons. Firstly, before the /usr merge there was no /share, so we had to place them in /lib. Secondly I think that /lib is actually the better fit for them, simply because I consider them closely related to the code they wrap, and code belongs in lib, libexec or bin. How does that matter? Well, the unit files are very often dependendent on/closely related to the architecture, and make little sense to share them between archs. This applies to a couple of units we ship with systemd itself (for example the hugepages mount unit), but even more often to unit we don't ship ourselves (think mcelog). And distributing these unit files among a number of dirs would seriously suck.
This sounds like the unit files belong in %{_libdir} now? However, that would mean that they can't go into noarch packages. So we probably need to know a little more about just how architecture dependent these unit files can be.
-Toshio
On Mon, 20.02.12 09:25, Toshio Kuratomi (a.badger@gmail.com) wrote:
On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
On Fri, 17.02.12 10:46, Nathaniel McCallum (nathaniel@natemccallum.com) wrote:
I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3].
Seriously, please don't do this.
The unit files are in /lib for a couple of reasons. Firstly, before the /usr merge there was no /share, so we had to place them in /lib. Secondly I think that /lib is actually the better fit for them, simply because I consider them closely related to the code they wrap, and code belongs in lib, libexec or bin. How does that matter? Well, the unit files are very often dependendent on/closely related to the architecture, and make little sense to share them between archs. This applies to a couple of units we ship with systemd itself (for example the hugepages mount unit), but even more often to unit we don't ship ourselves (think mcelog). And distributing these unit files among a number of dirs would seriously suck.
This sounds like the unit files belong in %{_libdir} now? However, that would mean that they can't go into noarch packages. So we probably need to know a little more about just how architecture dependent these unit files can be.
No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship two different versions for 32bit and 64bit. We want just one, hence they belong in /lib unconditionally)
Best way to specify the path is %{_unitdir} however, which points to the actual unit dir, and has been updated for the /usr merge already.
Lennart
On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
On Mon, 20.02.12 09:25, Toshio Kuratomi (a.badger@gmail.com) wrote:
On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
On Fri, 17.02.12 10:46, Nathaniel McCallum (nathaniel@natemccallum.com) wrote:
I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3].
Seriously, please don't do this.
The unit files are in /lib for a couple of reasons. Firstly, before the /usr merge there was no /share, so we had to place them in /lib. Secondly I think that /lib is actually the better fit for them, simply because I consider them closely related to the code they wrap, and code belongs in lib, libexec or bin. How does that matter? Well, the unit files are very often dependendent on/closely related to the architecture, and make little sense to share them between archs. This applies to a couple of units we ship with systemd itself (for example the hugepages mount unit), but even more often to unit we don't ship ourselves (think mcelog). And distributing these unit files among a number of dirs would seriously suck.
This sounds like the unit files belong in %{_libdir} now? However, that would mean that they can't go into noarch packages. So we probably need to know a little more about just how architecture dependent these unit files can be.
No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship two different versions for 32bit and 64bit. We want just one, hence they belong in /lib unconditionally)
Okay, so this is one more area where when people mispackage a library and a program in the same subpackage, they'll get bitten?
Fair enough.
-Toshio
On Mon, Feb 20, 2012 at 20:18, Toshio Kuratomi a.badger@gmail.com wrote:
On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
On Mon, 20.02.12 09:25, Toshio Kuratomi (a.badger@gmail.com) wrote:
This sounds like the unit files belong in %{_libdir} now? However, that would mean that they can't go into noarch packages. So we probably need to know a little more about just how architecture dependent these unit files can be.
No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship two different versions for 32bit and 64bit. We want just one, hence they belong in /lib unconditionally)
Okay, so this is one more area where when people mispackage a library and a program in the same subpackage, they'll get bitten?
I'm convinced that the default of $libexedir should just be set to /usr/lib and all packages using libexecdir should use a subdir in that, and $libdir should not be involved at all, this results in /usr/lib/udev/cdrom_id, and /usr/lib/systemd/systemd-journald and so on. This is actually what most distributions do today and what we envision for the future of a cross-distribution unified Linux.
The general rule for $libdir is that it is reserved for shared objects and their directly associated files like pkgconfig files.
There are valid cases where shared objects exec() their own helpers, like when elevated privileges and setuid/capabilities are involved, that can be a good and valid reason to drop the binary in $libdir if multilib installation with separate callout helpers need to be supported; but almost all other packages should not mess there.
Kay
On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers kay.sievers@vrfy.org wrote:
The general rule for $libdir is that it is reserved for shared objects and their directly associated files like pkgconfig files.
No, that's not at all what the FHS says. Please don't claim that any suggested meaning, however reasonable it may be, is "the general rule" when it isn't. Mirek
2012/2/20 Miloslav Trmač mitr@volny.cz:
On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers kay.sievers@vrfy.org wrote:
The general rule for $libdir is that it is reserved for shared objects and their directly associated files like pkgconfig files.
No, that's not at all what the FHS says.
"Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory."
Please don't claim that any suggested meaning, however reasonable it may be, is "the general rule" when it isn't.
I do.
Kay
On Mon, Feb 20, 2012 at 9:29 PM, Kay Sievers kay.sievers@vrfy.org wrote:
2012/2/20 Miloslav Trmač mitr@volny.cz:
On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers kay.sievers@vrfy.org wrote:
The general rule for $libdir is that it is reserved for shared objects and their directly associated files like pkgconfig files.
No, that's not at all what the FHS says.
"Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory."
That's the /usr/lib paragraph. The $libdir paragraph is
"4.8.1.�Purpose
/usr/lib<qual> performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/lib<qual>/sendmail and /usr/lib<qual>/X11 are not required. [28]"
i.e. "equivalent to /usr/lib, no additional restrictions." Mirek
On Mon, Feb 20, 2012 at 09:17:30PM +0100, Kay Sievers wrote:
On Mon, Feb 20, 2012 at 20:18, Toshio Kuratomi a.badger@gmail.com wrote:
On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
On Mon, 20.02.12 09:25, Toshio Kuratomi (a.badger@gmail.com) wrote:
This sounds like the unit files belong in %{_libdir} now? However, that would mean that they can't go into noarch packages. So we probably need to know a little more about just how architecture dependent these unit files can be.
No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship two different versions for 32bit and 64bit. We want just one, hence they belong in /lib unconditionally)
Okay, so this is one more area where when people mispackage a library and a program in the same subpackage, they'll get bitten?
I'm convinced that the default of $libexedir should just be set to /usr/lib and all packages using libexecdir should use a subdir in that,
So I have to admit here that I have no idea why systemd is using $libexecdir here. The definition of libexecdir does not support the storing of unit files:
""" libexecdir
The directory for installing executable programs to be run by other programs rather than by users. This directory should normally be ‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you are using Autoconf, write it as ‘@libexecdir@’.)
The definition of ‘libexecdir’ is the same for all packages, so you should install your data in a subdirectory thereof. Most packages install their data under ‘$(libexecdir)/package-name/’, possibly within additional subdirectories thereof, such as ‘$(libexecdir)/package-name/machine/version’. """
unit files are declarative, not executable. It sounds like upstream systemd wants to use $(exec_prefix)/lib/systemd for the unit files and is attempting to shoehorn those into libexecdir because some distros set libexecdir to ${exec_prefix}/lib whereas some distros on some arches set libdir to ${exec_prefix}lib64 This is incorrect use of libexecdir. They should just use ${exec_prefix}/lib if that is the place that makes the most sense.
(Or make up a new config variable that they submit to the GNU coding standards).
-Toshio
On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" a.badger@gmail.com wrote:
This sounds like the unit files belong in %{_libdir} now? However, that would mean that they can't go into noarch packages. So we probably need
to
know a little more about just how architecture dependent these unit files can be.
There is some serious confusion going on here with Fedora and libexec, not only regarding the lib/ vs share/ problem.
The recommended defaults as mentioned in the packaging guidelines are just plain wrong. The recent bug we opened regarding this was just closed wontfix.
Udev rules and systemd units belong to the installed daemon. This daemon can only exist exactly one single time, and never be installed by multilib packages, hence they do not ever belong into libdir. We support compat arch only, not multiarch. Multiarch would look completely different anyway, and compat arch does not need or want to involve libdir here.
The rules and units belong in 'libexecdir' which is upstream, and by LSB, called and defined as /usr/lib/<pkgname>. Putting anything like that into libdir is just wrong.
What the Fedora guidlines recommend here is not only wrong, it is also playing bad with upstream, and as mentioned in the bug, I personally consider it upstream-unfriendly, upstream-ignorant and against all common sense in reducing the Linux distro balcanization, and just a bad example how not to package tools today.
Please stop recommending or installing tools or other non shared objects in libdir, they almost never belong there. I can see that a few exceptions can be granted here, because it makes it easier to support binaries, that are actually exclusively and directly bundled with a shared object, but everything else just does not belong into libdir.
Thanks, Kay
Le Lun 20 février 2012 18:50, Kay Sievers a écrit :
On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" a.badger@gmail.com wrote:
Udev rules and systemd units belong to the installed daemon. This daemon can only exist exactly one single time, and never be installed by multilib packages, hence they do not ever belong into libdir.
Actually, Udev rules and systemd units belong to the package that installed them. That's why hiding them in a private lib dir is wrong
When amavisd instaciates clamav using the generic unit shipped with clamav but using an amavisd-specific conf file the clamav systemd unid is shared with amavisd
That's why share is the natural place to share this arch-independant configuration and putting it in /usr/lib is grandfathering an exception that only existed because /share didn't exist
On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Lun 20 février 2012 18:50, Kay Sievers a écrit :
On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" a.badger@gmail.com wrote:
Udev rules and systemd units belong to the installed daemon. This daemon can only exist exactly one single time, and never be installed by multilib packages, hence they do not ever belong into libdir.
Actually, Udev rules and systemd units belong to the package that installed them. That's why hiding them in a private lib dir is wrong
When amavisd instaciates clamav using the generic unit shipped with clamav but using an amavisd-specific conf file the clamav systemd unid is shared with amavisd
That's why share is the natural place to share this arch-independant configuration and putting it in /usr/lib is grandfathering an exception that only existed because /share didn't exist
I couldn't disagree more.
/usr/share in our general understanding not to be used for package-private things. There is no reason to have /usr/share/<pkgdir>/ and /usr/lib/<pkgdir>, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share.
Even the original distinction between arch-dependent and arch-independent to support a share/ subdir that can be *shared* between different machines will break with config like udev and systemd in share/. This is not a *natural* place at all.
We tend to interpret /usr/share as something today, to place stuff into that is really *shared* on the same host, like icons, man pages, things that are mere a collection of similar stuff that multiple packages use. It's definitely not a place to store system instructions and system plugins.
Kay
On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.sievers@vrfy.org wrote:
/usr/share in our general understanding not to be used for package-private things.
Who is "we"? This is in direct conflict with the FHS:
"Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose."
There is no reason to have /usr/share/<pkgdir>/ and /usr/lib/<pkgdir>, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share.
Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-gene... .
Even the original distinction between arch-dependent and arch-independent to support a share/ subdir that can be *shared* between different machines will break with config like udev and systemd in share/. This is not a *natural* place at all.
What would break in particular? From a quick grep there is not a single mention of "lib64" in any of the configuration/control files in either /lib/systemd or /lib/udev on my F16 system.
We tend to interpret /usr/share as something today, to place stuff into that is really *shared* on the same host, like icons, man pages, things that are mere a collection of similar stuff that multiple packages use.
Again, who is "we" here? FHS is pretty explicit about the intended distinction between "lib" and "share".
(And FWIW, none my comments above is to be read to be in favor of moving anything just to make things "prettier" or "more consistent".) Mirek
Am 20.02.2012 21:19, schrieb Miloslav Trmač:
On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.sievers@vrfy.org wrote:
/usr/share in our general understanding not to be used for package-private things.
Who is "we"? This is in direct conflict with the FHS:
"Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose."
There is no reason to have /usr/share/<pkgdir>/ and /usr/lib/<pkgdir>, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share.
Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-gene...
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGAN...
/usr/lib : Libraries for programming _and_ packages
Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory.
For example, the perl5 subdirectory for Perl 5 modules and libraries.
On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer harald.hoyer@gmail.com wrote:
Am 20.02.2012 21:19, schrieb Miloslav Trmač:
On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.sievers@vrfy.org wrote:
There is no reason to have /usr/share/<pkgdir>/ and /usr/lib/<pkgdir>, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share.
Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-gene...
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGAN...
/usr/lib : Libraries for programming _and_ packages
Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory,
There is equivalent language in the /usr/share section, with no indication that the two are supposed to be exclusive.
all architecture-dependent data exclusively used by the application must be placed within that subdirectory.
Again, equivalent language in the /usr/share section talks about architecture-independent data. When coupled with the front parts of FHS, it's quite clear that the intent is to split the application's data between the two directories.
BTW, pedantic reading of FHS seems not to support at all the concept of an application-defined directory into which other applications are supposed to store additional files. That's a pretty unreasonable interpretation, however.
(I think there is sort of a good reason not to require doing the lib vs. share split in Fedora - adding one more directory to check is a not a packaging change, it is a semantic change, it would be now necessary to somehow handle the case when lib and share each contain a different file with the same name. In my view, a lot of the "interesting" udev and systemd really belong to /etc anyway...) Mirek
Am 21.02.12 14:37, schrieb Miloslav Trmač:
On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer harald.hoyer@gmail.com wrote:
Am 20.02.2012 21:19, schrieb Miloslav Trmač:
On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.sievers@vrfy.org wrote:
There is no reason to have /usr/share/<pkgdir>/ and /usr/lib/<pkgdir>, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share.
Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-gene...
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGAN...
/usr/lib : Libraries for programming _and_ packages
Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory,
There is equivalent language in the /usr/share section, with no indication that the two are supposed to be exclusive.
all architecture-dependent data exclusively used by the application must be placed within that subdirectory.
Again, equivalent language in the /usr/share section talks about architecture-independent data. When coupled with the front parts of FHS, it's quite clear that the intent is to split the application's data between the two directories.
BTW, pedantic reading of FHS seems not to support at all the concept of an application-defined directory into which other applications are supposed to store additional files. That's a pretty unreasonable interpretation, however.
(I think there is sort of a good reason not to require doing the lib vs. share split in Fedora - adding one more directory to check is a not a packaging change, it is a semantic change, it would be now necessary to somehow handle the case when lib and share each contain a different file with the same name. In my view, a lot of the "interesting" udev and systemd really belong to /etc anyway...) Mirek
Well, as recently stated on the FHS mailing list, the FHS just documents common practice and does not set new standards. So, if we want a new standard in the FHS, we will have to invent, document and ship it. Same thing was happening when Red Hat/Fedora started with /usr/libexec and /run. It's now documented, even though only RH/Fedora uses /usr/libexec.
On Wed, Feb 22, 2012 at 7:46 AM, Harald Hoyer harald.hoyer@gmail.com wrote:
Am 21.02.12 14:37, schrieb Miloslav Trmač:
On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer harald.hoyer@gmail.com wrote:
Am 20.02.2012 21:19, schrieb Miloslav Trmač:
On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.sievers@vrfy.org wrote:
There is no reason to have /usr/share/<pkgdir>/ and /usr/lib/<pkgdir>, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share.
Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-gene...
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGAN...
/usr/lib : Libraries for programming _and_ packages
Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory,
There is equivalent language in the /usr/share section, with no indication that the two are supposed to be exclusive.
all architecture-dependent data exclusively used by the application must be placed within that subdirectory.
Again, equivalent language in the /usr/share section talks about architecture-independent data. When coupled with the front parts of FHS, it's quite clear that the intent is to split the application's data between the two directories.
<snipped>
Well, as recently stated on the FHS mailing list, the FHS just documents common practice and does not set new standards. So, if we want a new standard in the FHS, we will have to invent, document and ship it.
*shrug* What I really care about in this discussion is that incorrect claims that LSB/FHS mandates/allows something don't become accepted as general knowledge. Recently there have been rather many instances of "X is the standard and you need to follow it to stay compatible" when X were way too new to be considered a standard. Mirek
Le Lun 20 février 2012 21:07, Kay Sievers a écrit :
On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Lun 20 février 2012 18:50, Kay Sievers a écrit :
On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" a.badger@gmail.com wrote:
Udev rules and systemd units belong to the installed daemon. This daemon can only exist exactly one single time, and never be installed by multilib packages, hence they do not ever belong into libdir.
Actually, Udev rules and systemd units belong to the package that installed them. That's why hiding them in a private lib dir is wrong
When amavisd instaciates clamav using the generic unit shipped with clamav but using an amavisd-specific conf file the clamav systemd unid is shared with amavisd
That's why share is the natural place to share this arch-independant configuration and putting it in /usr/lib is grandfathering an exception that only existed because /share didn't exist
I couldn't disagree more.
/usr/share in our general understanding not to be used for package-private things.
But those files are not package-private! Even ignoring the example I just gave, systemd units *will* be installed by different packages that *will* need to be at least aware of the other units to handle ordering properly. Those files are anything but package-private
Le Lun 20 février 2012 21:20, Nicolas Mailhot a écrit :
Le Lun 20 février 2012 21:07, Kay Sievers a écrit :
I couldn't disagree more.
/usr/share in our general understanding not to be used for package-private things.
But those files are not package-private! Even ignoring the example I just gave, systemd units *will* be installed by different packages that *will* need to be at least aware of the other units to handle ordering properly. Those files are anything but package-private
(and actually it's quite ridiculous to have systemd people argue today unit files belong to them alone when they've spent the past years reusing files that were intended for sysv. Someday something better than systemd will be proposed and it will have to read 'systemd' files just like systemd had to read 'sysv' files to handle the transition)
On Mon, Feb 20, 2012 at 21:25, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Lun 20 février 2012 21:20, Nicolas Mailhot a écrit :
Le Lun 20 février 2012 21:07, Kay Sievers a écrit :
I couldn't disagree more.
/usr/share in our general understanding not to be used for package-private things.
But those files are not package-private! Even ignoring the example I just gave, systemd units *will* be installed by different packages that *will* need to be at least aware of the other units to handle ordering properly. Those files are anything but package-private
(and actually it's quite ridiculous to have systemd people argue today unit files belong to them alone when they've spent the past years reusing files that were intended for sysv. Someday something better than systemd will be proposed and it will have to read 'systemd' files just like systemd had to read 'sysv' files to handle the transition)
It all started with udev 7 years ago, and it still makes sense taking into account all the experience we collected in that time. Find it ridiculous or not, it's what we think is right. Even if we were not sure about it, changing the well-established way we do it would not be justified.
Kay