[systemd-devel] systemd convert

[Kay Sievers]

On Sun, Nov 25, 2012 at 11:39 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Lennart Poettering at 24/11/12 23:11 did gyre and gimble:
>> On Sat, 24.11.12 10:18, Dave (Bob) (dave at bob-the-boat.me.uk) wrote:
>>
>>> The only thing that I would be interested to know, is why what I would
>>> see as executables and cofiguration files are put in the 'lib'
>>
>> The binaries in /usr/lib/systemd are binaries that are more or less
>> internal to systemd, and never invoked directly by the user. Their
>> command interface is not considered stable, and should not pollute
>> $PATH.
>>
>> Also see this mail I sent in another thread today:
>>
>> http://lists.freedesktop.org/archives/systemd-devel/2012-November/007543.html
>>
>> In that mail I try to give an explanation of the scheme how we
>> distribute binaries between bindir, rootbindir and /usr/lib/systemd.
>
>
> I guess that answers the "binaries" bit, but probably doesn't answer why
> system units are in /usr/lib/systemd/system/ rather than, say,
> /usr/share/systemd/systemd. I think that's the "configuration files"
> part of Dave's question.
>
> That said, I don't think either is a "perfect" location anyway... I mean
> we don't really have a /usr/$NNN dir that really is equiv of /etc, but
> not for admin use. I guess some packages have opted for putting their
> config into /usr/share (e.g. alsa) and some into /usr/lib (e.g. systemd)
>
> It would have been nice to get a "global" standard here, but such is life.

Our very own "rule" here is:
-- /usr/share/<pkg>/ is for things that is read/used by *multiple*
packages, things that are kind of an ABI, stuff tham makes stability
promises. Icons, locale, timezone, man pages ...

Stuff that is only ever read and defined by a single package, like
D-Bus config is kind of wrong to install into shared.

--  /usr/lib/<pkg>/ is the "application private directory", it is only
read by one and the same package, not by any other thing. It's not
really official ABI, it's just a contract between tools that drop in
things here. It does not necessarily make promises. If /usr/lib/<pkg>/
exists, /usr/share/<pkg>/ should never exist at the same time.

The original interpretation of "host architecture independence" makes
almost no sense today, and we treat "shared" more as "shared between
applications"(multiple readers/users) than "possibly shared between
hosts". The stuff in shared/ makes more promises than stuff in lib/,
it should not or cannot be changed at will, or re-defined by a single
package.

Kay