[+cc lennart]
Lennart, I vaguely recall us talking about /usr/share during
DebConf. AFAIR, you had strong opinions on the distinction between lib
and share not working out? I may be wrong, but in case I’m not, I’d
appreciate it if you could comment on this thread briefly. Thanks.
Hi Axel,
Axel Beckert <a...@debian.org> writes:
> Justification: Policy 9.1.1 / FHS
>
> systemd demands that plain-text default configuration files (according
> to tmpfiles.d(5)) for temporary directories are placed under
> /usr/lib/tmpfiles.d/ and places at least one file there itself.
>
> This violates FHS as architecture independent files must not go under
> /usr/lib/ but under /usr/share/ instead.
>
> So please change /usr/lib/tmpfiles.d/ to /usr/share/tmpfiles.d/ (and
> maybe add a symlink from /usr/lib/tmpfiles.d/ to
> /usr/share/tmpfiles.d/).
While in general I applaud efforts to be more standards-compliant, I
think the FHS is getting increasingly out of date and less relevant to
Linux as a whole.
For this particular case (i.e. /usr/share should be used over
/usr/lib), I don’t think there’s any benefit whatsoever we’d get from
changing the path.
I read up on the FHS, and I found two sections relevant to this issue:
/usr/lib : Libraries for programming and packages
/usr/lib includes object files, libraries, and internal binaries
that are not intended to be executed directly by users or shell
scripts. [22]
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. [23]
And:
/usr/share : Architecture-independent data
The /usr/share hierarchy is for all read-only architecture
independent data files. [30]
This hierarchy is intended to be shareable among all architecture
platforms of a given OS; thus, for example, a site with i386, Alpha,
and PPC platforms might maintain a single /usr/share directory that
is centrally-mounted. Note, however, that /usr/share is generally
not intended to be shared by different OSes or by different releases
of the same OS.
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.
Now, the FHS says that architecture-dependent data _must_ be placed in
/usr/lib. It also says that /usr/share is for read-only architecture
independent data files.
Notably, it does not specify that you _must not_ place
architecture-independent data in /usr/lib.
Therefore, I don’t think we are violating the FHS with the systemd
package.
I’ll close the bug unless you manage to convince me otherwise,
preferably with an actual benefit that we’d get from changing the path,
apart from following some document with questionable relevancy to the
letter :-).
--
Best regards,
Michael
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
