On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mailhot@xxxxxxxxxxx) 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 -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
