systemd system unit files and UsrMove

Miloslav Trmač mitr at volny.cz
Wed Feb 22 06:50:50 UTC 2012


On Wed, Feb 22, 2012 at 7:46 AM, Harald Hoyer <harald.hoyer at gmail.com> wrote:
> 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.
<snipped>

> 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.

*shrug*  What I really care about in this discussion is that incorrect
claims that LSB/FHS mandates/allows something don't become accepted as
general knowledge.  Recently there have been rather many instances of
"X is the standard and you need to follow it to stay compatible" when
X were way too new to be considered a standard.
    Mirek


More information about the devel mailing list