Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Sean Whitton]

Hello Charles,

On Thu 22 Sep 2022 at 02:26PM +09, Charles Plessy wrote:

> So point taken about "paragraph", although interestingly, the
> Simple English definition of "paragraph" is quite spot on if one would
> replace "sentence" with "field": ”one or more sentences that are written
> together with no line breaks separating them.

I think that the quoted definition rather argues against 'paragraph' --
it makes it clear that being made up of sentences, and not
non-sentences, is essential to paragraph-hood.  In other words, it only
becomes spot on if you change the core meaning into a definition of
something else.

> I understand about avoiding ambiguity, but in my opinion it is the price
> to pay to be able to translate information into simple words from
> English to non-European languages.  Although the Policy itself is not
> going to be translated, I think that it can be advantageous if its
> contents can be discussed in simple words in people's native languages.

It may yet be translated!  We have the po4a setup :)

-- 
Sean Whitton

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Charles Plessy]

Hi Russ,

Le Tue, Sep 20, 2022 at 06:08:16PM -0700, Russ Allbery a écrit :
> 
> I do find the use of paragraph the way we were previously using it to
> be confusing, particularly given that the paragraphs contain fields
> which in turn contain actual paragraphs in the normal sense of the
> term.

> I don't want to keep using paragraph, but I'd be open to some other term
> that Guillem was also open to (I think matching the terminology in dpkg is
> very important).  Section or block are commonly used for things like this,
> but aren't very precise, so I'm not that enthused by them.

In the spec, the word "paragraph" is only used in the specified context,
so I always felt that there is no ambiguity.  But of course, it can
create opportunities for misunderstanding when discussing about the
spec.  So point taken about "paragraph", although interestingly, the
Simple English definition of "paragraph" is quite spot on if one would
replace "sentence" with "field": ”one or more sentences that are written
together with no line breaks separating them.  Usually they are
connected by a single idea.” ()

The use of "paragraph" in the current spec is also consistent with
Chapter 5 of the Policy, which also uses the word "paragraph".  By the
way, in section 5.6.26 of the Policy, the word "stanza" is also used to
mean something else than a "paragraph".

I do not mind the word "section".  It is the term used in the manual
page "systemd.syntax" that describes systemd's unit files, which means
that readers may be already familiar with the concept.  One could argue
that its definition in Simple English
(, “A section of a thing or
place is a part of it”) would allow a reader to think that a Field is
also a section, but I feel it is unlikely to happen.  This said, one big
disadvantage of "section" is that when searching for this word in a
document, there may be a lot of noisy hits such as "refer to section xyz
for details".

I understand about avoiding ambiguity, but in my opinion it is the price
to pay to be able to translate information into simple words from
English to non-European languages.  Although the Policy itself is not
going to be translated, I think that it can be advantageous if its
contents can be discussed in simple words in people's native languages.

Cheers,

-- Charles

Re: Idea for Policy expert reviewer list

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> What do people think?  Helpful innovation, or just extra
Russ> bookkeeping that isn't worth the effort?  If people do think
Russ> this is a good idea, I'll bring it up on debian-devel for
Russ> further discussion (and then, if we adopted it, it would be a
Russ> debian-devel-announce post).

I think I'd recommend waiting until you get burned a couple times by not
having the review before implementing something like this.
I've watched the expert review process in the IETF become more involved
over the years, and I think it's important to be careful of  against process
complexity increases.  Mind I think the IETF complexity increases may be
justified: the impact of standards errors today is bigger than it was in
2000.
And it may be that we've reached the point to start down that road in
Debian.
But I'd prefer to have concrete things we're accomplishing with a change
like this.  They might look like:

* I'm an expert in foo area, but debian-policy is too much traffic, and
  I'm struggling to keep up

or

* We didn't get enough review and we made a mistake with the bar
  change.  We have experts who would have done the review if asked but
  do not read debian-policy.

--Sam

Bug#970234: consider dropping "No hard links in source packages"

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Sam Hartman  writes:

>> I think that hard links in a source package are fine provided
>> that breaking the hard links would not either break the build or
>> provide an unreasonable space multiplier.

Russ> I agree with you that those would be undesirable properties,
Russ> but are they likely and important enough to have it be worth
Russ> retaining a section talking about this, as opposed to using
Russ> the "not every bug is a Policy violation" rule?  We do pay a
Russ> (small) complexity cost for each additional requirement we put
Russ> in Policy, so I'm tempted to just drop this entirely and bank
Russ> the complexity reduction.

You have me sold on not likely enough to matter.
I do think that having the build break (or worse produce bad results) on
hard link breaking would be a really important problem because of how
much it violates the principle of least surprise, but I agree that it is
unlikely enough that it need not be covered in policy.

--Sam

Bug#975631: debian-policy: window manager: remove reference to Debian menu

[Simon McVittie]

On Tue, 20 Sep 2022 at 21:45:28 -0700, Russ Allbery wrote:
> I just found https://bugs.debian.org/838777, which says packages that only
> provide a window manager without a mechanism for launching programs should
> not register as x-window-manager

See also https://bugs.debian.org/1004522 in which I proposed adding a
wayland-session virtual package, and in the process, ended up also proposing
x-session for /usr/share/xsessions/*.desktop.

In particular https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004522#30
has a brief survey of what display managers actually do, and
in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004522#66 I tried to
document existing practice (which contradicts #838777).

> try to document what x-window-manager is really for in the new X world

This is part of what I tried to do in #1004522, but I was trying to
document what it is now (including literally-only-a-window-manager window
managers like mutter, not just tiny-desktop-environment window managers
like twm or openbox), rather than what it should be.

If we redefine x-window-manager to mean something that is more strict than
it is now, then we'll have a mixture of x-window-manager implementations
that meet the new requirement, and (perhaps essentially unmaintained)
x-window-manager implementations that don't; so I'm not sure that's such a
good idea. That's why I proposed adding a new virtual package instead.

I personally think the fully-integrated-system approach should be
that packages that want to be considered to be a session that you
can log into (potentially ranging from GNOME/KDE all the way down to
twm) should register themselves in /usr/share/xsessions/*.desktop
(or /usr/share/wayland-sessions/*.desktop), user-friendly display
managers like gdm/lightdm/sddm should list those and only those,
and people who want to construct their own tiny desktop environment
out of a window manager and some xterms should enable it by installing
something resembling
https://salsa.debian.org/gnome-team/gdm/-/blob/debian/master/debian/custom-x11-session.desktop
into /etc/X11/sessions. gdm3 installs that file into
/usr/share/doc/gdm3/examples for sysadmin convenience, but intentionally
does not install it in the search path.

Rationale: people who want to piece together their own desktop environment
programmatically are welcome to do so, but that setup inherently requires
configuration. Trying to list ~/.xsession in UIs is confusing to novice
users, because the display manager cannot know what it will result in,
so its user-facing name has to be either very technical ("Xsession")
or hopelessly vague (older gdm's "System X11 Default") or both; so we
should not inflict that UX on users who have not done the necessary
setup to get it to behave as they want it to. For a setup that already
requires configuration before it will be usable, adding one more piece
of configuration doesn't seem like an undue burden.

gdm3 (>= bookworm), sddm, slim and lxdm already follow what I'm advocating
here.

smcv

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

[Holger Levsen]

On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
> +The autobuilders for the Debian backports suite do not perform this
> +transformation and instead use the full alternatives list to resolve
> +dependencies.
 
this sounds like they install all build depends, incl alternative ones?!
is that really the case? (and why?)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Make facts great again.


signature.asc
Description: PGP signature

Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages

[Holger Levsen]

On Tue, Sep 20, 2022 at 06:39:11PM -0700, Russ Allbery wrote:
> Here is proposed wording that I think is ready for seconds.
> 
> From: Russ Allbery 
> Date: Tue, 20 Sep 2022 18:35:55 -0700
> Subject: [PATCH] Clarify udeb-only source packages are out of scope
> 
> Note that source packages that only produce udebs are, like udebs,
> out of scope and may not follow all of the requirements of Policy.
> 
> Say explicitly in the Standards-Version description that udebs and
> source packages that only produce udebs do not use Standards-Version.
> ---
>  policy/ch-controlfields.rst |  3 +++
>  policy/ch-scope.rst | 10 +-
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 428b8a7..ea8f4a3 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -540,6 +540,9 @@ Thus only the first three components of the policy 
> version are
>  significant in the *Standards-Version* control field, and so either
>  these three components or all four components may be specified. [#]_
>  
> +udebs and source packages that only produce udebs do not use
> +``Standards-Version``.
> +
>  .. _s-f-Version:
>  
>  ``Version``
> diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst
> index 289c9a9..a279c26 100644
> --- a/policy/ch-scope.rst
> +++ b/policy/ch-scope.rst
> @@ -71,11 +71,11 @@ Much of the information presented in this manual will be 
> useful even
>  when building a package which is to be distributed in some other way or
>  is intended for local use only.
>  
> -udebs (stripped-down binary packages used by the Debian Installer) do
> -not comply with all of the requirements discussed here. See the `Debian
> -Installer internals
> -manual `_ for
> -more information about them.
> +udebs (stripped-down binary packages used by the Debian Installer) and
> +source packages that produce only udebs do not comply with all of the
> +requirements discussed here. See the `Debian Installer internals manual
> +`_ for more information
> +about them.

seconded, thanks.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's not the lockdown which is unbearable, but the virus.


signature.asc
Description: PGP signature

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

[Wouter Verhelst]

On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
> Wouter Verhelst  writes:
> > On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote:
> >> Wouter Verhelst  writes:
> 
> >>> -policy: this is a question that has come up before
> >>> (https://lists.debian.org/debian-devel/2016/12/msg00470.html is
> >>> another example that springs to mind, but I'm pretty sure there are
> >>> more), so I think we should document in Policy that a) buildd only
> >>> looks at the first dependency in alternative build-dependencies, and
> >>> b) why this is the case.
> 
> >> Policy already says:
> 
> >> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch
> >> permit the use of alternative dependencies, these are not normally
> >> used by the Debian autobuilders. To avoid inconsistency between
> >> repeated builds of a package, the autobuilders will default to
> >> selecting the first alternative, after reducing any
> >> architecture-specific restrictions for the build architecture in
> >> question. While this may limit the usefulness of alternatives in a
> >> single release, they can still be used to provide flexibility in
> >> building the same package across multiple distributions or
> >> releases, where a particular dependency is met by differently named
> >> packages.
> 
> >> in 7.1.  However, it's hidden in a footnote.  Perhaps we should make it
> >> more prominant (and make it clear that it's normative), and tweak the
> >> wording.
> 
> > Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
> > (probably after debconf though)
> 
> Here, a couple of years later, is a patch that does this, and which I
> think is ready for seconds.

Whoops, sorry; this completely slipped my mind.

> -- 
> Russ Allbery (r...@debian.org)  
> 

> From dd30c5455f13086dd0ef90bf6890c20729a1ac0b Mon Sep 17 00:00:00 2001
> From: Russ Allbery 
> Date: Tue, 20 Sep 2022 19:11:54 -0700
> Subject: [PATCH] Improve alternative build dependency discussion
> 
> Alternatives in build dependencies are normally (except for
> backports) handled specially by autobuilders to try to maintain
> consistent builds.  This was documented in Policy, but in a
> footnote that people often didn't see.
> 
> Move this text into the main body of the discussion of build
> dependencies and reword it for additional clarity.  Add a pointer
> to this discussion where alternative dependencies are introduced.
> ---
>  policy/ch-relationships.rst | 41 ++---
>  1 file changed, 25 insertions(+), 16 deletions(-)
> 
> diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
> index 5074428..f177885 100644
> --- a/policy/ch-relationships.rst
> +++ b/policy/ch-relationships.rst
> @@ -15,7 +15,10 @@ control fields of the package, which declare dependencies 
> on other
>  packages, the package names listed may also include lists of alternative
>  package names, separated by vertical bar (pipe) symbols ``|``. In such a
>  case, that part of the dependency can be satisfied by any one of the
> -alternative packages.  [#]_
> +alternative packages. (Alternative dependencies in ``Build-Depends``,
> +``Build-Depends-Indep``, and ``Build-Depends-Arch`` are normally used in a
> +restricted way. See :ref:`Relationships between source and binary packages
> +` for more details.)
>  
>  All of the fields may restrict their applicability to particular versions
>  of each named package. This is done in parentheses after each individual
> @@ -620,6 +623,27 @@ earlier for binary packages) in order to invoke the 
> targets in
>  ``Build-Conflicts-Arch`` fields must be satisfied when these targets
>  are invoked.
>  
> +Alternative dependencies are allowed in the ``Build-Depends``,
> +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's
> +autobuilders normally interpret them in a restricted way. After
> +dependencies that do not apply to the current architecture are removed,
> +all alternatives specifying different package names than the first
> +alternative are dropped. (Alternatives specifying the same package name
> +are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.)
> +The effect, therefore, is to use only the first alternative that is valid
> +on the relevant architecture. This is done to reduce the risk of
> +inconsistencies between repeated builds.

I think this could be expanded a bit?

"This is done to reduce the risk of inconsistencies between repeated
builds, in case a package is temporarily not available to be installed
on a given architecture (which due to the nature of the unstable
distribution might happen for any number of reasons) at the time of the
(re-)build of a package."

or something along those lines. The point is to make it clear how these
inconsistencies are caused, which I think will help with understanding.

(I realize your text is what the footnote