Re: Bug#846970: Patch to document Build-Indep-Architecture field

[Nik Nyby]

UNSUBSCRIBE

On 06/14/2018 03:49 PM, Jess Hall wrote:

On Sat, 14 Oct 2017 Sean Whitton wrote:

On Sat, Oct 14 2017, Mattia Rizzolo wrote:

On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote:

+maintainer's control.  The specification should entail that the
+architecture-independent packages are buildable on at least two
+architectures.


[...]


Also, I dislike the sentence in itself, I believe it should be more
straightforward in conveying its meaning of "pretty please at least
two arch".


It has to be that way for cases like this:

 Build-Indep-architecture: !amd64

That entails that it builds on at least two architectures, but on a
common reading of 'specify', it does not specify two archs.


How about "You should not specify that the packages are buildable on
only one architecture."?

Bug#846970: Patch to document Build-Indep-Architecture field

[Jess Hall]

On Sat, 14 Oct 2017 Sean Whitton wrote:
> On Sat, Oct 14 2017, Mattia Rizzolo wrote:
> > On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote:
> >> +maintainer's control.  The specification should entail that the
> >> +architecture-independent packages are buildable on at least two
> >> +architectures.

[...]

> > Also, I dislike the sentence in itself, I believe it should be more
> > straightforward in conveying its meaning of "pretty please at least
> > two arch".
> 
> It has to be that way for cases like this:
> 
> Build-Indep-architecture: !amd64
> 
> That entails that it builds on at least two architectures, but on a
> common reading of 'specify', it does not specify two archs.

How about "You should not specify that the packages are buildable on
only one architecture."?

-- 
Jess Hall

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 ``/usr

Processed: Re: Bug#567033: Decide if we should continue recommending /usr/games

[Debian Bug Tracking System]

Processing control commands:

> unmerge 567033
Bug #567033 [debian-policy] Decide if we should continue recommending /usr/games
Ignoring request to unmerge a bug which is not merged with any others.

-- 
567033: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567033
787816: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787816
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#567033: Decide if we should continue recommending /usr/games

[Debian Bug Tracking System]

Processing control commands:

> unmerge 567033
Bug #567033 [debian-policy] Decide if we should continue recommending /usr/games
Bug #787816 [debian-policy] Replace FHS 2.3 by FHS 3.0 in the Policy.
Disconnected #567033 from all other report(s).

-- 
567033: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567033
787816: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787816
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#567033: Decide if we should continue recommending /usr/games

[Simon McVittie]

Control: unmerge 567033

On Fri, 11 Aug 2017 at 07:07:49 -0700, Sean Whitton wrote:
> The latest version of the FHS does not have /usr/games, so merging this
> with the bug about updating our FHS version.

Removing the games directories was considered in

and , but there
was no consensus. The FHS 3.0 as published by the Linux Foundation says
essentially the same things games as FHS 2.3:

> [/usr/]games  Games and educational binaries (optional)
> ...
> [/usr/share/]gamesStatic data files for /usr/games (optional)
> ...
> Similarly, a /usr/lib/games hierarchy may be used in addition to the
> /usr/share/games hierarchy if the distributor wishes to place some game
> data there.

(/usr/local/games is technically also mandatory, although I'm sure
that's an oversight and it was meant to be optional...)

Debian can choose to put games in the /.../games directories, or in the
standard directories /usr/bin, /usr/share etc., or any mixture of our
choice, orthogonal to whether/when we move to FHS 3.0.

smcv

Bug#880920: Document Rules-Requires-Root field

[Paul Gevers]

I want to second this text, but have some questions.

> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 0771346..3519d99 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst

> @@ -1020,6 +1022,118 @@ This field is automatically added to Debian source 
> control files
>  field may also be used in source package control files
>  (``debian/control``) if needed in other situations.
>
> +.. _s-f-Rules-Requires-Root:
> +
> +``Rules-Requires-Root``
> +~~~
> +
> +Simple field that defines if the source package requires access to
> +root (or fakeroot) during selected targets in the :ref:`Main building
> +script: debian/rules `.
> +
> +The field can consist of exactly one of the following three items:
> +
> + - ``no``: Declares that neither root nor fakeroot is required.
> +   Package builders (e.g. dpkg-buildpackage) may choose to invoke any
> +   target in ``debian/rules`` with an unprivileged user.
> +
> + - ``binary-targets`` (default): Declares that the package will need
> +   the root (or fakeroot) when either of the ``binary``,
> +   ``binary-arch`` or ``binary-indep`` targets are called.  This is
> +   how every tool behaved before this field was defined.
> +
> + - A space separated list of keywords described below.  These must
> +   always contain a forward slash, which sets them apart from the
> +   other values.  When this list is provided, the builder must provide

^^ plural here, makes sense.

> +   a `gain root command` (as defined in :ref:`debian/rules and
> +   Rules-Requires-Root `) *or* pretend that
> +   the value was set to ``binary-targets``, and both the builder and
> +   the package's ``debian/rules`` script must downgrade accordingly
> +   (see below).
> +
> +If the package builder supports the ``Rules-Requires-Root`` field and
> +want to enable the feature, then it must set the environment variable
> +``DEB_RULES_REQUIRES_ROOT`` when invoking the package building script
> +``debian/rules``.  The value of ``DEB_RULES_REQUIRES_ROOT`` should be
> +one of:
> +
> + * The value of ``Rules-Requires-Root`` if the builder can support

  ^ singular here. I find this ambiguous. I think you mean
to treat the list of values above as one variable by calling it singular
here, a suggested by the remark about space below.

> +   that value.  The builder may trim unnecessary whitespace used to
> +   format the field for readability.
> +
> + * The value ``binary-targets`` if it cannot support the value of
> +   ``Rules-Requires-Root``.
> +
> +A compliant builder may also leave ``DEB_RULES_REQUIRES_ROOT`` unset
> +or set it to ``binary-targets`` if it has been requested to test
> +whether the package it builds correctly implements the fall-back for
> +legacy builders.
> +
> +Remarks
> +^^^
> +
> +All packages and builders must support ``binary-targets`` as this was
> +the historical behaviour prior to the introduction of this field.
> +
> +Any tool (partiularly older versions of them) may be unaware of this
> +field and behave like the field was set to ``binary-targets``.  The
> +package build must gracefully cope with this and produce a
> +semantically equivalent result.
> +
> +This field intentionally does not enable a package to request a true
> +root over fakeroot.

Apparently some details in the implementation are unclear to me, as I
don't get this statement if the example at the end includes a sudo
example. Isn't that a true root or is that not what you mean? Is only
$(su root) a real root (and why wouldn't that work)?

> +
> +Definition of the keywords
> +^^
> +
> +The keywords have the format ``/``, where:
> +
> + *  must consist entirely of printable ASCII characters
> +   except for any whitespace and the forward slash (``/``).  It must
> +   consist of at least 2 characters.
> +
> + * ``/`` (between  and ) is a single ASCII
> +   forward slash.
> +
> + *  must consist entirely of printable ASCII characters
> +   except for any whitespace.  It must consist of at least 2
> +   characters.
> +
> +These keywords define where the package build script ``debian/rules``,
> +or the tools called by that script, will need access to root or
> +fakeroot.
> +
> +In addition to the keywords defined in the next section, each tool or
> +package may define keywords within a namespace named after that tool
> +or package.  The package or tool is considered to own that namespace.
> +
> +A tool may use the `gain root command` to do something under

  ^^^ a?
   ^ should this be linked to the
*section describing it? It drops out of thin air here.

> +(fake)root if and only if the tool defines an appropriate keyword in
> +its namespace, and the package lists that keyword in
> +``Rules-Requires-Root``.
> +
> +All tools must ignore keywords under namespaces they do not know or
> +own.  A tool may emit a warning, or abort with an

Bug#897217: debian-policy: Vcs-Hg should support -b too

[Andrej Shadura]

On Mon, 30 Apr 2018 09:55:03 +0200 Samuel Thibault
 wrote:
> Hello,
> 
> In 5.6.26, one can read about Vcs-:
> 
> "In the case of Git, the value consists of a URL, optionally followed by
> the word -b the name of a branch in the indicated repository, following
> the syntax of the git clone command".
> 
> It would be useful to have the same for Hg, for instance:
> 
> "In the case of Git and Hg, the value consists of a URL, optionally
> followed by the word -b the name of a branch in the indicated
> repository, following the syntax of the git clone and hg clone
> commands".

Actually, with hg there’s not much need for this since the native hg URL
format supports specifying the branch to check out in a URL fragment:
https://server.org/path/to/repo#branch.

-- 
Cheers,
  Andrej

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Simon McVittie]

On Sat, 14 Oct 2017 at 15:28:04 -0700, Sean Whitton wrote:
> On Sat, Oct 14 2017, Adam D. Barratt wrote:
> > The 2016 edition is Technical Corrigendum 2. I'm not sure that it's
> > conventional to use versioning such as 4.2 in such cases, however. I'd
> > expect it to be referred to as SUSv4, SUSv4TC2, or SUSv4 2016 edition;
> > the latter seems to be more common.

http://pubs.opengroup.org/onlinepubs/9699919799/ has now been replaced
(see #900882, for which I'm preparing a patch) with POSIX.1-2017, which
is variously labelled as:

* POSIX.1-2017
* IEEE Std 1003.1-2017
* The Open Group Technical Standard Base Specifications, Issue 7
* The Open Group Base Specifications Issue 7, 2018 Edition

and no longer has visible "Single Unix Specification" branding at all.
However, the downloadable tarballs at
http://pubs.opengroup.org/onlinepubs/9699919799/download/
have basename susv4-2018. According to Wikipedia it "incorporates Singles
UNIX Specification TC1 and TC2, and is technically identical to the
2016 edition."

I'd suggest replacing SUSv3 with POSIX.1-2017 or SUSv4 2018 edition
instead, or perhaps replacing SUSv3 with POSIX and clarifying that we
use POSIX to refer to the latest version of the POSIX.1 standard.

smcv

Processed: tagging 891216

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 891216 - patch + pending
Bug #891216 [debian-policy] Requre d-devel consultation for epoch bump
Removed tag(s) patch.
Bug #891216 [debian-policy] Requre d-devel consultation for epoch bump
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
891216: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891216
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems