Hello, On Thu, Jun 28 2018, Simon McVittie wrote: >> 2. The requirement for amd64 libraries to be installed to /lib64 have >> been removed, so we can drop/reword our exception for that (point 3 in >> 9.1.1 in current Policy) > > OK, so more like this? > > On 64-bit architectures, only the dynamic linker and libc are allowed to > install files in /lib64. > > (Or perhaps without the "On 64-bit architectures" prefix, but I don't > know whether we have any 32-bit architectures with 64-bit multilib > that uses /lib64 other than for the dynamic linker and libc. lib64z1 > is a multilib variant of a library that normally lives on the rootfs, > and it uses /usr/lib64, so perhaps that situation doesn't actually exist.) Let's drop the "On 64-bit architectures..." because it makes the requirement simpler. >> 3. We are violating the new requirements that /usr/local/share/color >> must exist if /usr/share/color exists. I guess we just need to file >> a bug after policy is updated. > > apt-file says we would need to file bugs against argyll-ref, colord-data, > icc-profiles, icc-profiles-free, krita-data and libgs9-common. I don't > have krita-data installed so I didn't inspect it, but none of the others > have maintainer scripts, except for argyll-ref which does some trivial > symlink-to-dir conversion. Thanks for generating this list. > I can't help thinking that adding maintainer scripts to those > packages is a lot of effort to go to to have an extra directory in > /usr/local/share, particularly with the elaborate dance involving > /etc/staff-group-for-usr-local that dh_usrlocal is now required to > perform. Can't sysadmins create that directory themselves if they want it? > Might it be better to add an exception so that everything we do now is > still allowed, in the same spirit as the /usr/bin/mh thing? > > We could even extend the current point > > The requirement for /usr/local/libqual to exist if /libqual or > /usr/libqual exists (where libqual is a variant of lib such as lib32 > or lib64) is removed. > > and turn it into > > All requirements for /usr/local/foo to exist if /foo or /usr/foo > exists (where foo is any directory specified by the FHS) are removed. > > After all, the code with fewest bugs is the code that isn't there :-) > (This doesn't mean packages can't create those directories if they want > to: Policy §9.1.2 says they still can.) > > I'm not really sure why the FHS has requirements of the form "if > /usr/foo exists then /usr/local/foo must exist" anyway. I think what > they really mean might be "if an OS component reads /usr/foo, then it > must read /usr/local/foo, if it exists, with higher precedence" but > neither actually implies the other. That's a good point about maintainer scripts. It is good to include exceptions to the FHS that reduce the number of bugs in Debian. On the other hand, we probably shouldn't be too ready to assume that the FHS authors didn't have a good reason for including the requirement. So how about adding a bullet point that says that the requirement is relaxed to a recommendation? Then it is a normal severity bug at most, if not lower. >> > +11. The requirement for there to be no subdirectories in ``/usr/bin`` >> > + is relaxed to allow the ``mh`` mail-handling suite to create >> > + ``/usr/bin/mh/``, as was allowed in FHS version 2.3. >> >> I think this needs to be worded more strongly so that it is clear that >> the mh case is the /only/ exception. > > OK; that was my intention, but it could have been clearer. How about: > > As an exception to the requirement for there to be no subdirectories > in ``/usr/bin``, the ``mh`` mail-handling suite may create > ``/usr/bin/mh/``, as was allowed in FHS version 2.3. Other > subdirectories are not allowed. > > (This means mailutils-mh, owner of /usr/bin/mu-mh/, continues to > be technically non-Policy-compliant, but that's a matter for its > maintainers. We could always add a second exception later if they > want one.) LGTM. >> [1] I did this by: >> >> % apt-get install git-remote-bzr >> % git clone bzr::http://bzr.linuxfoundation.org/lsb/devel/fhs-spec >> >> and then look at every commit after the first, which imports FHS 2.3. > > I'll check that the version I imported from a web server matches what's > in that bzr repository. The bzr repo had release tags so I think we're pretty safe. > I don't intend to import the complete source > including its bundled copy of docbook-xsl, only the bits that I already > imported. Agreed. Thank you for your continued efforts! -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature