Re: Splitting in /usr/lib/<arch> and /usr/share
Andrey Rahmatullin <wrar@wrar.name> writes:
> On Mon, Mar 10, 2014 at 11:39:22AM +0100, Оlе Ѕtrеісhеr wrote:
>> >> >> I am packaging some older software (eso-midas, [1]) that installs
>> >> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
>> >> >> the FHS requires that this should be split between /usr/share/ and
>> >> >> /usr/lib/<arch>/.
>> >> > Nothing forbids you from putting arch-indep files into /usr/lib.
>> >>
>> >> FHS does: "Miscellaneous architecture-independent application-specific
>> >> static files and subdirectories must be placed in /usr/share." [1]
>> > Do we enforce this?
>>
>> "9.1.1 File System Structure
>>
>> The location of all files and directories must comply with the
>> Filesystem Hierarchy Standard (FHS), version 2.3, with the exceptions
>> noted below, and except where doing so would violate other terms of
>> Debian Policy. [...]" [2]
>>
>> I would interpret this as: Yes, we do.
> I mean do we check this in e.g. lintian. I also wonder if finding an
> arch-indep file in /usr/lib should result in an RC bug.
>From the BTS documentation [1]:
| The severity levels are:
| [...]
| serious
|
| is a severe violation of Debian policy (roughly, it violates a
| "must" or "required" directive), or, in the package maintainer's or
| release manager's opinion, makes the package unsuitable for release.
|
| [...]
| Certain severities are considered release-critical, [...]
| Currently, these are critical, grave and serious.
Since the Policy 9.1.1 states (see above) "... *must* comply with the
FHS", I would assume that the current agreement is that an
arch-independent file in /usr/lib/ is an RC bug. When this was not the
intention, it should be clarified in the policy (or the BTS docs).
Best regards
Ole
[1] https://www.debian.org/Bugs/Developer
Reply to: