[trimming CC]
Hello Simon,
On Thu, Jun 14 2018, Simon McVittie wrote:
> I've prepared patches for this, which are available here:
> https://salsa.debian.org/smcv/policy/merge_requests/1/diffs
>
> I've attached them here, except for the patch that replaces the bundled
> copy of FHS v2.3 with a bundled copy of FHS v3.0, which is inconveniently
> large.
Many thanks for this work.
>I think patch 0002 is the only normative one?
Yes, we need discuss only the patch that touches 9.1.1.
I have reviewed all the upstream commits between FHS 2.3 and FHS 3.0[1]
and I think your patch captures them, except:
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).
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)
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.
> The only thing I found that would make Debian non-compliant is the
> fact that the /usr/bin/mh/ directory used to be allowed, but is not
> allowed any more. For the moment I think this should be documented as a
> departure from FHS v3.0, and if anyone cares enough about removing that
> exception, it should be discussed with the maintainers of nmh (which ships
> /usr/bin/mh/) and mailutils-mh (which is technically non-Policy-compliant,
> although does comply with the spirit of the policy) on a separate bug.
Yes, adding an exception makes sense.
Inline questions & suggestions:
> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 7d85c00..b18e2c2 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -12,7 +12,7 @@ File System Structure
> ~~~~~~~~~~~~~~~~~~~~~
>
> The location of all files and directories must comply with the
> -Filesystem Hierarchy Standard (FHS), version 2.3, with the exceptions
> +Filesystem Hierarchy Standard (FHS), version 3.0, with the exceptions
> noted below, and except where doing so would violate other terms of
> Debian Policy. The following exceptions to the FHS apply:
>
> @@ -76,25 +76,20 @@ Debian Policy. The following exceptions to the FHS apply:
> ``/etc``, or at least are symlinked there, is relaxed to a
> recommendation.
>
> -8. The additional directory ``/run`` in the root file system is
> - allowed. ``/run`` replaces ``/var/run``, and the subdirectory
> - ``/run/lock`` replaces ``/var/lock``, with the ``/var`` directories
> - replaced by symlinks for backwards compatibility. ``/run`` and
> - ``/run/lock`` must follow all of the requirements in the FHS for
> - ``/var/run`` and ``/var/lock``, respectively, such as file naming
> - conventions, file format requirements, or the requirement that files
> - be cleared during the boot process. Files and directories residing
> - in ``/run`` should be stored on a temporary file system.
> +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.
Can you say why you made this change? If this is not trivial we should
probably do it in a separate bug.
I am also a little uncomfortable with the use of 'equivalent' without a
definition. If you wrote "equivalent, i.e. using symbolic links or
bind-mounts" there would be an implicit definition of 'equivalent' and
that would be better, but would of course restrict how the directories
may be made equivalent.
> +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.
[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.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature