Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Julien Cristau]

On 07/03/2018 11:56 AM, Simon McVittie wrote:
> How about the attached patch?
> 
> Complete patch series (including non-normative) updated here:
> https://salsa.debian.org/smcv/policy/merge_requests/1/diffs
> Seconded.

Cheers,
Julien

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Sean Whitton]

Hello,

On Tue, Jul 03 2018, Simon McVittie wrote:

> How about the attached patch?

Seconded:

>>From 5205d0a50465cf422f1040d9395d5ea83dbfde5f Mon Sep 17 00:00:00 2001
> From: Simon McVittie 
> Date: Thu, 14 Jun 2018 11:43:04 +0100
> Subject: [PATCH 3/3] Update to FHS v3.0
>
> Notable changes that this causes:
>
> * A GNU-style /usr/libexec is now allowed.
>
> Notable non-changes:
>
> * /usr/games, /usr/share/games and /usr/lib/games were optional in
>   FHS 2.3, and are still optional. It is up to us whether we want
>   to keep using those directories.
>
> Drop our special exception for /run, and replace it with a requirement
> that /var/run and /var/lock are symlinks to /run and /run/lock
> respectively. The FHS does not mandate that these directories are
> symlinked or bind-mounted (although I think it should) and some
> misguided distributions make /run and /var/run non-equivalent, but they
> have always been equivalent on Debian.
>
> Drop our special exception for /sys, which is now standardized in the
> FHS.
>
> Relax the requirement to create /usr/local/share/color to a
> recommendation to avoid making 6 packages immediately noncompliant.
>
> Add a special exception for /usr/bin/mh/ for now, restoring the FHS
> 2.3 situation (dropping this might be a good idea, but should be
> disussed with the nmh and mailutils-mh maintainers if desired).
>
> Signed-off-by: Simon McVittie 
> Closes: #787816
> ---
>  policy/ch-opersys.rst | 33 +
>  1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index f9f878f..cded697 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:
>
> @@ -34,9 +34,8 @@ Debian Policy. The following exceptions to the FHS apply:
>  is recommended the configuration files not start with the '.'
>  character.
>
> -3.  The requirement for amd64 to use ``/lib64`` for 64 bit binaries is
> -removed.  Only the dynamic linker and libc are allowed to use this
> -directory.
> +3.  Only the dynamic linker and libc are allowed to install files
> +in ``/lib64``.
>
>  4.  The requirement for object files, internal binaries, and libraries,
>  including ``libc.so.*``, to be located directly under ``/lib{,32}``
> @@ -76,20 +75,13 @@ 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.  ``/var/run`` is required to be a symbolic link to ``/run``,
> +and ``/var/lock`` is required to be a symbolic link to ``/run/lock``.
>
> -9.  The ``/sys`` directory in the root filesystem is additionally
> -allowed.  [#]_
> +9.  The ``/var/www`` directory is additionally allowed.
>
> -10. The ``/var/www`` directory is additionally allowed.
> +10. The requirement for ``/usr/local/share/color`` to exist if
> +``/usr/share/color`` exists is relaxed to a recommendation.
>
>  11. The requirement for ``/usr/local/libqual`` to exist if ``/libqual``
>  or ``/usr/libqual`` exists (where ``libqual`` is a variant of
> @@ -98,6 +90,11 @@ Debian Policy. The following exceptions to the FHS apply:
>  12. On GNU/Hurd systems, the following additional directories are
>  allowed in the root filesystem: ``/hurd`` and ``/servers``.  [#]_
>
> +13. 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.
> +
>  The version of this document referred here can be found in the
>  ``debian-policy`` package or on `FHS (Debian
>  copy) `_ alongside
> @@ -1028,10 +1025,6 @@ Debian, so this section has been removed.
> This is necessary for architecture-dependent headers file to coexist
> in a ``multiarch`` setup.
>
> -.. [#]
> -   This 

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Simon McVittie]

How about the attached patch?

Complete patch series (including non-normative) updated here:
https://salsa.debian.org/smcv/policy/merge_requests/1/diffs

On Thu, 28 Jun 2018 at 14:04:28 +0100, Sean Whitton wrote:
> On Thu, Jun 28 2018, Simon McVittie wrote:
> > On 64-bit architectures, only the dynamic linker and libc are allowed to
> > install files in /lib64.
> 
> Let's drop the "On 64-bit architectures..." because it makes the
> requirement simpler.

Done

> 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.

Done

> > 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.
> 
> LGTM.

Applied

> > I'll check that the version I imported from a web server matches what's
> > in that bzr repository.

It does (I removed an extra file that was only on the web server but
not in bzr, containing links to the various generated documents)

Thanks,
smcv
>From 5205d0a50465cf422f1040d9395d5ea83dbfde5f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 14 Jun 2018 11:43:04 +0100
Subject: [PATCH 3/3] Update to FHS v3.0

Notable changes that this causes:

* A GNU-style /usr/libexec is now allowed.

Notable non-changes:

* /usr/games, /usr/share/games and /usr/lib/games were optional in
  FHS 2.3, and are still optional. It is up to us whether we want
  to keep using those directories.

Drop our special exception for /run, and replace it with a requirement
that /var/run and /var/lock are symlinks to /run and /run/lock
respectively. The FHS does not mandate that these directories are
symlinked or bind-mounted (although I think it should) and some
misguided distributions make /run and /var/run non-equivalent, but they
have always been equivalent on Debian.

Drop our special exception for /sys, which is now standardized in the
FHS.

Relax the requirement to create /usr/local/share/color to a
recommendation to avoid making 6 packages immediately noncompliant.

Add a special exception for /usr/bin/mh/ for now, restoring the FHS
2.3 situation (dropping this might be a good idea, but should be
disussed with the nmh and mailutils-mh maintainers if desired).

Signed-off-by: Simon McVittie 
Closes: #787816
---
 policy/ch-opersys.rst | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index f9f878f..cded697 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:
 
@@ -34,9 +34,8 @@ Debian Policy. The following exceptions to the FHS apply:
 is recommended the configuration files not start with the '.'
 character.
 
-3.  The requirement for amd64 to use ``/lib64`` for 64 bit binaries is
-removed.  Only the dynamic linker and libc are allowed to use this
-directory.
+3.  Only the dynamic linker and libc are allowed to install files
+in ``/lib64``.
 
 4.  The requirement for object files, internal binaries, and libraries,
 including ``libc.so.*``, to be located directly under ``/lib{,32}``
@@ -76,20 +75,13 @@ 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.  ``/var/run`` is required to be a symbolic link to ``/run``,
+and ``/var/lock`` is required to be a symbolic link to ``/run/lock``.
 
-9.  The ``/sys`` directory in the root filesystem is additionally
-allowed.  [#]_
+9.  The ``/var/www`` directory is additionally allowed.
 
-10. The ``/var/www`` directory is additionally allowed.
+10. The requirement for ``/usr/local/share/color`` to exist if
+``/usr/share/color`` exists is relaxed to a recommendation.
 
 11. The requirement for ``/usr/local/libqual`` to exist if ``/libqual``

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Sean Whitton]

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


signature.asc
Description: PGP signature

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Simon McVittie]

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 

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Sean Whitton]

[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


signature.asc
Description: PGP signature

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Simon McVittie]

On Fri, 15 Jun 2018 at 14:37:04 +0200, Bill Allombert wrote:
> There are already 28 /usr/lib/TUPLE/*/bin directories in unstable.
> There are probably other directories with binaries not named bin.
> 
> They are candidates for being moved to /usr/libexec, but they should
> probably go to /usr/libexec/TUPLE at least to avoid file conflicts.

Packages are free to continue to use /usr/lib/TUPLE/PACKAGE/bin if they
want to, even after /usr/libexec exists, and I think that should be
best-practice for any packages that would otherwise collide.

FHS 3.0 explicitly says that it's OK for packages to install helper
binaries into either /usr/lib{,64} or /usr/libexec, although they should
choose one or the other, not both; so we are not making these packages
immediately buggy by adopting FHS 3.0. One of the design principles
for FHS 3.0 was that most FHS 2.3 systems should be obviously FHS
3.0 compliant without changes. (The only counter-example I'm aware of
is /usr/bin/mh/, for which I added an exemption in my proposed patch
for now.)

I would anticipate that the way we move to /usr/libexec would be:

* maintainers who want it explicitly use
  --libexecdir='${exec_prefix}/libexec' (some of these maintainers
  are currently using --libexecdir='${libdir}', as I did in src:ostree,
  for the reasons outlined in #859724)

* some future debhelper compat level (perhaps 12 or 13) changes the
  dh_auto_configure defaults from --libexecdir='${libdir}' to the
  Autoconf upstream default --libexecdir='${exec_prefix}/libexec'
  (and maybe the same for non-Autotools build systems like CMake)

* when maintainers change their packages to that compat level, in
  addition to adjusting their debian/*.install files, they are expected
  to check that they aren't introducing multiarch non-coinstallability
  in any Multi-Arch: same packages, and if necessary specify
  --libexecdir='${libdir}' explicitly (I expect this to be rare in
  practice)

* packages that install their helper binaries to ${libdir} or a
  subdirectory are unaffected, and will continue to install them in
  /usr/lib or a subdirectory indefinitely

Expanding on that last point, there are two ways an upstream can
install libexec-style helper binaries with Automake: they can put
them in ${libdir} (or more likely ${pkglibdir}) or they can put them
in ${(pkg)libexecdir}.  For the former, the binaries would remain in
/usr/lib/TUPLE by default and there's no multiarch collision.

For the latter, if there was going to be a collision, then the maintainer
would have to deal with this at the time that they bump debhelper compat
level to opt-in to the changed behaviour; but I don't think this problem
case will happen much in practice, because the same upstream package would
already have been troublesome to install on Red-Hat-like biarch systems
where ${libdir} is /usr/lib{,64} but ${libexecdir} is always /usr/libexec,
so any affected upstream projects have probably already been fixed by
users of Red-Hat-like distros.

When switching from libexecdir=${libdir} to
libexecdir=${exec_prefix}/libexec, maintainers already need to check
that their package isn't breaking the expectations of other packages
(or older versions of their library that might still be in RAM), just
like they did at the transition from libexecdir=${libdir}/${DEB_SOURCE}
to libexecdir=${libdir} when moving from debhelper compat level 8 to 9
(or from cdbs to dh 9 for packages that used to use cdbs).

smcv

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Bill Allombert]

On Sun, Jun 25, 2017 at 11:28:11PM +0100, Simon McVittie wrote:
> On Sun, 25 Jun 2017 at 22:37:04 +0200, Bill Allombert wrote:
> > I assume if we allow /usr/libexec, we also need to support
> > /usr/libexec/x86_64-linux-gnu/ etc. ?
> 
> I'm not sure I see why we would? Platforms with the "multilib" lib/lib64
> duality (Red Hat derivatives, etc.) only have one /usr/libexec, just like
> they only have one /usr/bin; so anything that expects a per-architecture
> libexecdir is already broken on more or less everything other than Debian.

> I'd expect a future Debian with FHS 3.0 in Policy to have
> libdir=/usr/lib/TUPLE and libexecdir=/usr/libexec as the normal settings
> for Autoconf.

There are already 28 /usr/lib/TUPLE/*/bin directories in unstable.
There are probably other directories with binaries not named bin.

They are candidates for being moved to /usr/libexec, but they should
probably go to /usr/libexec/TUPLE at least to avoid file conflicts.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Simon McVittie]

On Fri, 05 Jun 2015 at 20:43:10 +0900, Charles Plessy wrote:
> Le Thu, Jun 04, 2015 at 07:09:00PM -0700, Russ Allbery a écrit :
> > I have not looked at this at all, but this list should be aware that it
> > exists.
> 
> > The LSB workgroup is happy to announce the release of FHS 3.0.
> ... 
> > Release notes can be found here:
> > 
> > https://wiki.linuxfoundation.org/en/FHSReleaseNotes30

Unfortunately those release notes have vanished, but a copy can be found at:
https://web.archive.org/web/20160624022300/wiki.linuxfoundation.org/en/FHSReleaseNotes30

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. I think patch 0002 is the only normative one?

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.

I got my copy of the FHS source code from
http://refspecs.linuxfoundation.org/FHS_3.0/ (which contains source and
compiled copies), not from
http://bzr.linuxfoundation.org/loggerhead/lsb/devel/fhs-spec/changes
(which I only found later), and I didn't include the bundled copy of
docbook-xsl or the outdated FHS in draft.sgml. I used a directory
instead of a tarball, for better transparency.

> By the way, I wonder if the debian-policy package is the best place for
> shipping a copy of the FHS.

Probably not, but let's not delay its adoption by another 3 years while
we paint that particular bike shed :-)

smcv
>From 8867b0b88d311739fd360f1f6dc945406c39ed54 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 14 Jun 2018 11:43:04 +0100
Subject: [PATCH 2/3] Update to FHS v3.0

Notable changes that this causes:

* A GNU-style /usr/libexec is now allowed.

Notable non-changes:

* /usr/games, /usr/share/games and /usr/lib/games were optional in
  FHS 2.3, and are still optional. It is up to us whether we want
  to keep using those directories.

Drop our special exception for /run, and replace it with a requirement
that the pairs (/run, /var/run) and (/run/lock, /var/lock) are made
equivalent via symlinks or bind mounts. The FHS does not mandate this
(although I think it should) and some misguided distributions make
/run and /var/run non-equivalent, but they have always been equivalent
on Debian.

Drop our special exception for /sys, which is now standardized in the
FHS.

Add a special exception for /usr/bin/mh/ for now, restoring the FHS
2.3 situation (dropping this might be a good idea, but should be
disussed with the nmh and mailutils-mh maintainers if desired).

Signed-off-by: Simon McVittie 
Closes: #787816
---
 policy/ch-opersys.rst | 29 ++---
 1 file changed, 10 insertions(+), 19 deletions(-)

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.
 
-9.  The ``/sys`` directory in the root filesystem is additionally
-allowed.  [#]_
+9.  The ``/var/www`` directory is additionally allowed.
 
-10. The ``/var/www`` directory is additionally allowed.
-
-11. The requirement for 

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Simon McVittie]

On Sun, 25 Jun 2017 at 22:37:04 +0200, Bill Allombert wrote:
> I assume if we allow /usr/libexec, we also need to support
> /usr/libexec/x86_64-linux-gnu/ etc. ?

I'm not sure I see why we would? Platforms with the "multilib" lib/lib64
duality (Red Hat derivatives, etc.) only have one /usr/libexec, just like
they only have one /usr/bin; so anything that expects a per-architecture
libexecdir is already broken on more or less everything other than Debian.

I'd expect a future Debian with FHS 3.0 in Policy to have
libdir=/usr/lib/TUPLE and libexecdir=/usr/libexec as the normal settings
for Autoconf.

(On the other hand, there's probably no reason why we'd specifically
forbid /usr/libexec/TUPLE either.)

More background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859724

S

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Bill Allombert]

On Sun, Jun 25, 2017 at 08:26:00AM +, Niels Thykier wrote:
> On Fri, 5 Jun 2015 20:43:10 +0900 Charles Plessy  wrote:
> > Package: debian-policy
> > Severity: normal
> > 
> > Le Thu, Jun 04, 2015 at 07:09:00PM -0700, Russ Allbery a écrit :
> > > I have not looked at this at all, but this list should be aware that it
> > > exists.
> > 
> > > Date: Wed, 03 Jun 2015 09:19:04 -0400
> > > Subject: [fhs-discuss] FHS 3.0
> > > 
> > > The LSB workgroup is happy to announce the release of FHS 3.0.
> > ... 
> > > Release notes can be found here:
> > > 
> > > https://wiki.linuxfoundation.org/en/FHSReleaseNotes30
> > 
> > Thanks Russ for the heads-up.
> > 
> > Judging from the release notes, it would not be too hard to update the 
> > Policy's
> > description of how Debian follows and deviates from the FHS.
> > 
> > By the way, I wonder if the debian-policy package is the best place for
> > shipping a copy of the FHS.  I just checked out the bzr repository that
> > contains its sources, and it builds out of the box (build-depends on xmlto 
> > and
> > fop).  Perhaps it would deserve its own package ?
> 
> I would like to see FHS 3.0 adopted as well.  Or an 2.3 exception to
> allow the use of /usr/libexec.

I assume if we allow /usr/libexec, we also need to support
/usr/libexec/x86_64-linux-gnu/ etc. ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Niels Thykier]

On Fri, 5 Jun 2015 20:43:10 +0900 Charles Plessy  wrote:
> Package: debian-policy
> Severity: normal
> 
> Le Thu, Jun 04, 2015 at 07:09:00PM -0700, Russ Allbery a écrit :
> > I have not looked at this at all, but this list should be aware that it
> > exists.
> 
> > Date: Wed, 03 Jun 2015 09:19:04 -0400
> > Subject: [fhs-discuss] FHS 3.0
> > 
> > The LSB workgroup is happy to announce the release of FHS 3.0.
> ... 
> > Release notes can be found here:
> > 
> > https://wiki.linuxfoundation.org/en/FHSReleaseNotes30
> 
> Thanks Russ for the heads-up.
> 
> Judging from the release notes, it would not be too hard to update the 
> Policy's
> description of how Debian follows and deviates from the FHS.
> 
> By the way, I wonder if the debian-policy package is the best place for
> shipping a copy of the FHS.  I just checked out the bzr repository that
> contains its sources, and it builds out of the box (build-depends on xmlto and
> fop).  Perhaps it would deserve its own package ?
> 
> Have a nice day,
> 
> Charles
> 
> -- 
> Charles Plessy
> Tsurumi, Kanagawa, Japan
> 
> 

Hi,

I would like to see FHS 3.0 adopted as well.  Or an 2.3 exception to
allow the use of /usr/libexec.

Thanks,
~Niels

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

[Charles Plessy]

Package: debian-policy
Severity: normal

Le Thu, Jun 04, 2015 at 07:09:00PM -0700, Russ Allbery a écrit :
 I have not looked at this at all, but this list should be aware that it
 exists.

 Date: Wed, 03 Jun 2015 09:19:04 -0400
 Subject: [fhs-discuss] FHS 3.0
 
 The LSB workgroup is happy to announce the release of FHS 3.0.
... 
 Release notes can be found here:
 
 https://wiki.linuxfoundation.org/en/FHSReleaseNotes30

Thanks Russ for the heads-up.

Judging from the release notes, it would not be too hard to update the Policy's
description of how Debian follows and deviates from the FHS.

By the way, I wonder if the debian-policy package is the best place for
shipping a copy of the FHS.  I just checked out the bzr repository that
contains its sources, and it builds out of the box (build-depends on xmlto and
fop).  Perhaps it would deserve its own package ?

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org