Michael Biebl wrote: > On Mon, Mar 10, 2014 at 06:39:20PM -0400, Joey Hess wrote: > > The FHS requirement that architecture-independent application-specific > > static files be located in /usr/share is relaxed to a suggestion. > > > > In particular, a subdirectory of /usr/lib may be used by a package > > (or a collection of packages) to hold a mixture of > > architecture-independent > > and architecture-dependent files. However, when a directory is > > entirely composed of architecture-independent files, it should be > > located in /usr/share. > > There are various packages which ship only architecture-independent files in > /usr/lib/<foo> directories. One example is [0]. > What's the rationale to explicitly make a distinction between > directories holding only architecture-independent files and ones > consisting of a mixture? > > Since [0] would violate this should rule, what would that mean in > practice: still a bug, though non-RC severity (normal?)?
I intentionally worded the proposal to downgrade this kind of case from a currently pseudo-RC bug to a normal severity bug. It's still a bug under the proposal, because it diverges from the FHS. But in this specific case, /usr/lib/<dir> is an interface of the program, used by other software, and it would be more painful to change it in Debian to strictly comply with the FHS than it's worth. The nice thing about non-rc severity bug reports is they can be forwarded upstream without undue urgency. IMHO this is more likely to yeild constructive results than the current state where we have some vast number of unreported RC bugs that have to be treated with high urgency, but only when someone is unkind enough to point out they exist.. -- see shy jo
signature.asc
Description: Digital signature