systemd system unit files and UsrMove

[Harald Hoyer]

Am 21.02.12 14:37, schrieb Miloslav Trmač:
> On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer <harald.hoyer at 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 at 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-generic/execenvfhs.html
>>
>> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
>>
>> /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.