On Sat, 23 Jun 2018 at 21:05:07 +0100, Sean Whitton wrote:
> 1. FHS 3.0 allows distributions to create directory hierarchies under
> user's home directories conforming to the XDG Base Directories or
> the GLib conventions on user directory contents.
>
> We don't permit packages to install to home directories or
> maintscripts to touch home directories, so maybe we need to add an
> exception saying that packages can't actually do this (of course,
> programs installed by those packages can do it).
OK. Something like this?
Packages must not contain files in /home, and packages' maintainer
scripts must not write to users' home directories. The programs in
those packages may create directory hierarchies as described in
§3.8.3 "Home Directory Specifications and Conventions" when run
by a user.
I'm not so sure whether this belongs in the FHS section? I think it's a
point about how our packages are required to behave, rather than about the
directories that can exist and their purposes. The directory hierarchies
are still the same, regardless of how they're created.
> 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.)
> 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.
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.
> > +8. The ``/var/run`` and ``/var/lock`` directories are required to be
> > + made equivalent to ``/run`` and ``/run/lock`` respectively, for
> > + example using symbolic links or bind-mounts.
>
> The change here is not just to update to FHS 3.0 but also to allow bind
> mounting instead of symlinking, and indeed to allow any other way of
> making them "equivalent". The previous version of the text required
> symlinking. And FHS 3.0 only explicitly mentions symlinking.
OK, I'll require symlinking too. I was vaguely remembering that the
transition path between /var/run and /run had involved bind mounts under
at least some circumstances, but it'll be simpler to require that /var/run
is a symlink to /run and /var/lock is a symlink to /run/lock, as it is
on any reasonable system these days.
> > +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.)
> [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. I don't intend to import the complete source
including its bundled copy of docbook-xsl, only the bits that I already
imported.
Thanks,
smcv
