Bug#944920: Revise terminology used to specify requirements
David Bremner <david@tethera.net> writes:
> Sean Whitton <spwhitton@spwhitton.name> writes:
>>> - No package for a 64 bit architecture may install files in
>>> - ``/usr/lib64/`` or in a subdirectory of it.
>>> + Packages must not install files in ``/usr/lib64`` or in a subdirectory
>>> + of it.
>>
>> This seems to be a semantic change, generalising the requirement to all
>> packages?
> Well, I think you're both right. A lawyerly reading of policy might say
> 32 bit packages can install in /usr/lib64, but wouldn't that just be
> nonsensical, and maybe contradict other wording about FHS conformance
Yeah, that was my thought process, but I did totally break my own rule. I
can break this out into a separate change if that makes more sense. I was
trying to reword the sentence to avoid using "no ... may" and trying to
keep the 64-bit qualification seemed very awkward.
/usr/lib64 is for 64-bit architecture support the Red Hat way (instead of
the Debian multiarch approach), so no 32-bit package would ever
legitimately install files there.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: