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