Bug#911165: marked as done (debian-policy: drop requirement to ship sysvinit init script with same name)

[Debian Bug Tracking System]

Your message dated Tue, 20 Sep 2022 21:59:22 -0700
with message-id <87a66tfhlh@hope.eyrie.org>
and subject line Re: Bug#911165: debian-policy: drop requirement to ship 
sysvinit init script with same name
has caused the Debian Bug report #911165,
regarding debian-policy: drop requirement to ship sysvinit init script with 
same name
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
911165: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911165
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-policy
Version: 4.2.1.2
Severity: normal

This requirement is currently included in Debian Policy:

+---
| However, any package integrating with other init systems must also
| be backwards-compatible with sysvinit by providing a SysV-style init
| script with the same name as and equivalent functionality to any
| init-specific job
+---[ Debian Policy, 9.11 "Alternate init systems" ]

I propose to drop the requirement for the following reasons:

a. tor@.service has no init script with the same name. This should be
   fine. (Note: there is also both a "tor.service" and "tor" init
   script.)
b. ssh.socket for systemd has no equivalent in sysvinit at all.
   This should be fine.
c. It is better to ship integration with some init systems than
   no integration at all. (Including sysvinit scripts at all is not
   required, only when any other integrations are provided.)
d. Some sysvinit scripts might start multiple services at once,
   but this might be split into multiple units in other systems.
   This should be allowed.
e. It is unclear what "equivalent functionality" implies.  Does this
   include sandboxing features?  Socket activation (which might be
   important for startup order)?  Using the same file for configuration
   (some services can be configured in /etc/default/* for sysvinit,
   but use overrides for systemd)?

If one tries to accomodate all of this, only something along the lines
of "if there is a init-specific job and an (in some way) equivalent
SysV-style init script then both should have the same name" remains.

Ansgar
--- End Message ---
--- Begin Message ---
Version: 4.5.0.0

Ansgar  writes:

> This requirement is currently included in Debian Policy:

> +---
> | However, any package integrating with other init systems must also
> | be backwards-compatible with sysvinit by providing a SysV-style init
> | script with the same name as and equivalent functionality to any
> | init-specific job
> +---[ Debian Policy, 9.11 "Alternate init systems" ]

> I propose to drop the requirement for the following reasons:

[...]

This section was deleted as part of resolving #948115, so this was fixed
in the version with that change.  Closing this accordingly.

-- 
Russ Allbery (r...@debian.org)  --- End Message ---

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

[Russ Allbery]

Russ Allbery  writes:

> I considered whether instead of starting with a priority of 40, we
> should instead bump the priority if the window manager supports the
> desktop specification, but I think this is a place where the structure
> of X environments has changed over the years.  It used to be that the
> window manager was what handled application menus, but now that's
> normally done by some other component of the desktop environment, or
> even just some toolbar app or other type of plugin that the user has
> chosen, and the window manager may be just a window manager.

> Given that, I don't think there's anything useful we can say here about
> menu management.  Old-school window managers that don't use a desktop
> environment (fvwm2, for instance) may implement support for desktop
> files, or for the Debian menu system for that matter; newer ones are
> likely to not handle menus at all and expect some other component to
> deal with that.

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.  So I'm now not sure that just removing
the mention of the menu system is a complete fix and we may indeed need to
say something about handling *.desktop files, because x-window-manager may
really supposed to be a desktop environment.

I think we can keep this change in the next release because it doesn't
make anything worse, but we should probably also pursue #838777 and try to
document what x-window-manager is really for in the new X world.  (This is
almost certainly going to require advice from the folks who work on
desktop environments, since I have no idea how x-window-manager is used
today.)

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

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

[Russ Allbery]

Guillem Jover  writes:
> On Mon, 2020-06-22 at 18:51:21 -0700, Felix Lechner wrote:

>> Starting with an upcoming release, Lintian will check for the presence
>> of required and recommended fields in various packaging control files.
>> Our methods are probably not perfect, but it was brought to my
>> attention that 'dpkg-buildpackage -S' produces *.changes files without
>> 'Binary' and 'Description' fields.

> This is due to a fix in dpkg 1.19.3 prompted by #818618, which brought up
> an inconsistency in the handling of these fields
> (commit 4a4619831de8b8972f86b489660dc98f187cfa34 in dpkg.git). DAK got
> also fixed to accept these .changes files.

[...]

> The deb-changes(5) and policy state that these fields contain
> information for binary packages being uploaded. On a source-only upload,
> there are no such binaries, so the definition was internally
> inconsistent.  I think the only thing missing is policy clarifying that
> this field is only mandatory on non-source-only uploads.

Here is a patch to fix this wording in Policy.  I think it's ready for
seconds.

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

>From c98654d7effa875c6e11da16159ac3feded8f763 Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Tue, 20 Sep 2022 21:17:55 -0700
Subject: [PATCH] Binary and Description optional in .changes

In .changes files for source-only uploads, the Binary and
Description fields are not present.  Document this, and be clearer
in the description of the Description field for .changes files that
only descriptions of binary packages are included.
---
 policy/ch-controlfields.rst | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 428b8a7..f85f75d 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -278,7 +278,7 @@ The fields in this file are:
 
 -  :ref:`Source ` (mandatory)
 
--  :ref:`Binary ` (mandatory)
+-  :ref:`Binary `
 
 -  :ref:`Architecture ` (mandatory)
 
@@ -292,7 +292,7 @@ The fields in this file are:
 
 -  :ref:`Changed-By `
 
--  :ref:`Description ` (mandatory)
+-  :ref:`Description `
 
 -  :ref:`Closes `
 
@@ -809,12 +809,13 @@ See :ref:`s-descriptions` for further information on
 this.
 
 In a ``.changes`` file, the ``Description`` field contains a summary of
-the descriptions for the packages being uploaded. For this case, the
-first line of the field value (the part on the same line as
-``Description:``) is always empty. It is a multiline field, with one
-line per package. Each line is indented by one space and contains the
-name of a binary package, a space, a hyphen (``-``), a space, and the
-short description line from that package.
+the descriptions of the binary packages being uploaded. (``.changes``
+files for uploads containing only source packages will not have this
+field.) For this case, the first line of the field value (the part on the
+same line as ``Description:``) is always empty. It is a multiline field,
+with one line per binary package. Each line is indented by one space and
+contains the name of a binary package, a space, a hyphen (``-``), a space,
+and the short description line from that package.
 
 .. _s-f-Distribution:
 
@@ -924,7 +925,8 @@ every architecture. The source control file doesn't contain details of
 which architectures are appropriate for which of the binary packages.
 
 When it appears in a ``.changes`` file, it lists the names of the binary
-packages being uploaded, separated by whitespace (not commas).
+packages being uploaded, separated by whitespace (not commas). If only
+source packages are being uploaded, this field will not be present.
 
 .. _s-f-Installed-Size:
 
-- 
2.37.2

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 963524 ...

[Debian Bug Tracking System]

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

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> usertags 963524 normative
There were no usertags set.
Usertags are now: normative.
> tags 963524 + patch
Bug #963524 [debian-policy] debian-policy: Binary and Description fields not 
mandatory in .changes on source-only uploads
Added tag(s) patch.
> thanks
Stopping processing here.

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

Bug#967857: marked as done (debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable)

[Debian Bug Tracking System]

Your message dated Tue, 20 Sep 2022 21:05:38 -0700
with message-id <87o7v9fk31@hope.eyrie.org>
and subject line Re: Bug#967857: debian-policy: [Files/Permissions and owners] 
files installed by package manager should not be writable
has caused the Debian Bug report #967857,
regarding debian-policy: [Files/Permissions and owners] files installed by 
package manager should not be writable
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
967857: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967857
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-policy

Hi,

10.9 Permissions and owners currently says

| Files should be owned by root:root, and made writable only by the
| owner and universally readable (and executable, if appropriate),
| that is mode 644 or 755."

However most files shouldn't be modified as modifications will just be
lost (e.g. everything installed by the package manager that isn't
handled as a conffile).  It also gives more permissions than the
minimum needed.

I think static files should not be writable instead, so every file
under /usr (and /bin, /sbin, /lib*; or everything dpkg installs that is
not a conffile) should have 444 (or 555).

Ansgar
--- End Message ---
--- Begin Message ---
Ansgar  writes:

> Hi,

> 10.9 Permissions and owners currently says

> | Files should be owned by root:root, and made writable only by the
> | owner and universally readable (and executable, if appropriate),
> | that is mode 644 or 755."

> However most files shouldn't be modified as modifications will just be
> lost (e.g. everything installed by the package manager that isn't
> handled as a conffile).  It also gives more permissions than the
> minimum needed.

> I think static files should not be writable instead, so every file
> under /usr (and /bin, /sbin, /lib*; or everything dpkg installs that is
> not a conffile) should have 444 (or 555).

Coming back to this a couple of years later, it looks from the bug history
like we had a fairly extensive discussion of this with a lot of opposition
(for various different reasons) and not much support.  Given that, I'm
going to go ahead and close this out as wontfix, since I don't think we're
going to reach a consensus on this change.

-- 
Russ Allbery (r...@debian.org)  --- End Message ---

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 967857 ...

[Debian Bug Tracking System]

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

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> usertags 967857 normative
There were no usertags set.
Usertags are now: normative.
> tags 967857 + wontfix
Bug #967857 [debian-policy] debian-policy: [Files/Permissions and owners] files 
installed by package manager should not be writable
Added tag(s) wontfix.
> thanks
Stopping processing here.

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

Bug#883233: marked as done (First footnote to section 7.1 should say which of Debian's autobuilders ignore alternative dependencies)

[Debian Bug Tracking System]

Your message dated Tue, 20 Sep 2022 20:15:16 -0700
with message-id <87sfklfmez@hope.eyrie.org>
and subject line Re: Bug#883233: First footnote to section 7.1 should say which 
of Debian's autobuilders ignore alternative dependencies
has caused the Debian Bug report #883233,
regarding First footnote to section 7.1 should say which of Debian's 
autobuilders ignore alternative dependencies
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
883233: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883233
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-policy
Version: 4.1.2.0
Severity: normal
User: debian-pol...@packages.debian.org
Usertags: informative

On Thu, Nov 30 2017, Rebecca N. Palmer wrote:

> Should [section 7.1, footnote 1] also make explicit which Debian
> suites have this restriction?
>
> I thought this rule also applied to backports having found [0] in a list
> archive search, and hence have been explicitly changing dependencies for
> backports [1] instead of using alternatives.

Yes, good point.  Backports autobuilders use --build-dep-resolver=aptitude
which (I believe) considers alternative dependencies.

> However after finding this proposal, I checked build logs, which
> suggest that sid (including -ports architectures) and stable do but
> backports doesn't.  (Though we should probably check that with someone
> who knows this better before writing it into Policy...)

Agreed, we need some clarity.

wanna-build team / Release Team / Backports Team: exactly which buildds
ignore alternative dependencies?  We want to include this in an
(existing) Policy footnote.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 4.6.1.0

Sean Whitton  writes:
> On Thu, Nov 30 2017, Rebecca N. Palmer wrote:

>> Should [section 7.1, footnote 1] also make explicit which Debian
>> suites have this restriction?
>>
>> I thought this rule also applied to backports having found [0] in a list
>> archive search, and hence have been explicitly changing dependencies for
>> backports [1] instead of using alternatives.

> Yes, good point.  Backports autobuilders use --build-dep-resolver=aptitude
> which (I believe) considers alternative dependencies.

>> However after finding this proposal, I checked build logs, which
>> suggest that sid (including -ports architectures) and stable do but
>> backports doesn't.  (Though we should probably check that with someone
>> who knows this better before writing it into Policy...)

> Agreed, we need some clarity.

> wanna-build team / Release Team / Backports Team: exactly which buildds
> ignore alternative dependencies?  We want to include this in an
> (existing) Policy footnote.

I think they all do except for backports.  Subsequent to this bug being
filed, https://bugs.debian.org/999826 was filed and resulted in a change
that documented the backports behavior.

The current proposed patch to #968226 will hopefully further improve this
text, but I think the core of this bug was resolved by #999826.  I'm
therefore closing it as done in the upload that fixed that bug.

-- 
Russ Allbery (r...@debian.org)  --- End Message ---

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

[Russ Allbery]

Helmut Grohne  writes:

> Jakub stumbled into the "No hard links in source packages" requirement
> added around 1996 and couldn't make sense of it. Neither could Christoph
> nor myself. tar does support hard links just fine. lintian does not
> check this property. sugar-log-activity/38 is an example package
> violating the property. It is shipped in buster and technically rc-buggy
> though no bug is filed about it.

> I believe that the requriement needs a rationale. Failing that, it
> should be dropped.

I'm inclined to agree with you on this, but it's probably worth mentioning
somewhere in this bug that the AFS file system is still used and still, so
far as I know, does not support cross-directory hard links because of its
per-directory ACL system.  I'm not sure what tar does in this situation:
whether it fails or whether it just silently duplicates the file.

I'm not sure that we care, but that sort of concern (along with a general
dislike of hard links) is probably the original rationale.

The fact that this has gone unnoticed in a source package in an existing
release makes a pretty strong argument that nothing in Debian cares and we
should just remove the constraint.

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.

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

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

Bug#998282: Please make Section a required field for the source paragraph in d/control

[Russ Allbery]

Felix Lechner  writes:

> The installable stanzas in d/control (called "binary package paragraphs"
> in policy) inherit the Section field from the source paragraph. There is
> no reason to provide inheritance the other way around.

Huh, this pointed out to me that I don't know what the current behavior
is.  I think I've always put a Section field in the first stanza and then
overridden it as necessary, or at least I don't remember thinking about
this before.

The current Policy description of the Section field is rather cryptic:

This field specifies an application area into which the package has
been classified. See Sections.

When it appears in the debian/control file, it gives the value for the
subfield of the same name in the Files field of the .changes file. It
also gives the default for the same field in the binary packages.

I understand what it's trying to say, but that's a very mechanical
definition that isn't clear about the relationship between the Section
field in the source stanza and the Section field in the binary stanzas.
(It also claims Section is about an "application area," a term that I
don't think we use anywhere else in Policy.)

So, what happens today if you put Section in a binary stanza but not in
the source stanza?  Is it inherited from the binary stanza by the source
stanza (I agree that seems weird)?  If so, from which binary stanza is it
inherited, if there are several?  The definition of the Files field
implies that the section may just be - in some cases.

The current documentation certainly seems inadequate, although I'd like to
understand what the behavior of Debian software is before proposing
alternative wording.

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

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

[Russ Allbery]

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.

-- 
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.
+
+The autobuilders for the Debian backports suite do not perform this
+transformation and instead use the full alternatives list to resolve
+dependencies.
+
+While this rule for build dependencies may limit the usefulness of
+alternatives, they can still be used to provide flexibility when building
+the package outside of Debian's autobuilders, or when building it across
+multiple distributions or releases where a particular dependency is met by
+differently named packages.
+
 .. _s-built-using:
 
 Additional source packages used to build the binary - ``Built-Using``
@@ -666,21 +690,6 @@ requirements to retain the referenced source packages.  It should not
 be added solely as a way to locate packages that need to be rebuilt
 against newer versions of their build dependencies.
 
-.. [#]
-   While ``Build-Depends``

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 968226 ...

[Debian Bug Tracking System]

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

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> usertags 968226 = normative
There were no usertags set.
Usertags are now: normative.
> tags 968226 = patch
Bug #968226 [debian-policy] Move documentation of Build-Depends alternative 
selection out of footnote
Added tag(s) patch.
> thanks
Stopping processing here.

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

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 823256 ...

[Debian Bug Tracking System]

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

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> usertags 823256 = normative
Usertags were: normative proposal.
Usertags are now: normative.
> tags 823256 = patch
Bug #823256 [debian-policy] debian-policy: Update maintscript arguments with 
dpkg >= 1.18.5
Added tag(s) patch.
> usertags 992136 = normative
Usertags were: normative proposal.
Usertags are now: normative.
> tags 992136 = patch
Bug #992136 [debian-policy] Don't require Standards-Version field when only 
udebs Standards-Version for udeb packages
Added tag(s) patch.
> thanks
Stopping processing here.

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

Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5

[Russ Allbery]

Guillem Jover  writes:

> Starting with dpkg 1.18.5, several maintainer script actions involving a
> new package version, get that version as an argument after the old
> version, because they could not get it in any other easy way. The new
> version was only available in the new package somewhere in the
> filesystem.

> One previous way to workaround this limitation was to inject the new
> version at build time into those maintainer scripts, which is rather
> cumbersome, when dpkg already knows at run-time which new version it is
> handling.

> This was proposed and discussed some time ago in the debian-dpkg mailing
> list.

> The list of the actions and their new arguments, from the dpkg changelog
> entry are:

>   -  failed-upgrade  
>   -  abort-install  
>   -  abort-upgrade  
>   -  install  
>   -  upgrade  
>   -  failed-upgrade  

> Please, update the relevant section to mention those new arguments.

Here is a patch that I believe implements that, and which I think is ready
for seconds.

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

>From 2260f7a3aafe93282860aad07b7d8c1544bcf0ce Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Tue, 20 Sep 2022 18:49:04 -0700
Subject: [PATCH] new-version now passed to more maintainer scripts

Starting with dpkg 1.18.5, several maintainer script actions
involving a new package version get that version as an argument
after the old version. Update Policy's maintainer script
documentation accordingly.
---
 policy/ch-maintainerscripts.rst | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst
index 709aabf..724074c 100644
--- a/policy/ch-maintainerscripts.rst
+++ b/policy/ch-maintainerscripts.rst
@@ -107,8 +107,8 @@ old version of a package that is being upgraded from or downgraded from.
 The ``preinst`` script may be called in the following ways:
 
 | ``new-preinst`` install
-| ``new-preinst`` install *old-version*
-| ``new-preinst`` upgrade *old-version*
+| ``new-preinst`` install *old-version* *new-version*
+| ``new-preinst`` upgrade *old-version* *new-version*
 
 The package will not yet be unpacked, so the ``preinst`` script
 cannot rely on any files included in its package. Only essential
@@ -168,10 +168,10 @@ The ``prerm`` script may be called in the following ways:
 where dependencies are only "Half-Installed" due to a partial
 upgrade.
 
-``new-prerm`` failed-upgrade *old-version*
-Called during error handling when ``prerm upgrade`` fails. The new package will not yet be
-unpacked, and all the same constraints as for ``preinst upgrade``
-apply.
+``new-prerm`` failed-upgrade *old-version* *new-version*
+Called during error handling when ``prerm upgrade`` fails. The new
+package will not yet be unpacked, and all the same constraints as for
+``preinst upgrade`` apply.
 
 The ``postrm`` script may be called in the following ways:
 
@@ -189,7 +189,7 @@ The ``postrm`` script may be called in the following ways:
 the package's dependencies if those dependencies are unavailable.
 [#]_
 
-``new-postrm`` failed-upgrade *old-version*
+``new-postrm`` failed-upgrade *old-version* *new-version*
 Called when the old ``postrm upgrade`` action fails. The new package
 will be unpacked, but only essential packages and pre-dependencies
 can be relied on. Pre-dependencies will either be configured or will
@@ -197,8 +197,8 @@ The ``postrm`` script may be called in the following ways:
 configured and was never removed.
 
 | ``new-postrm`` abort-install
-| ``new-postrm`` abort-install *old-version*
-| ``new-postrm`` abort-upgrade *old-version*
+| ``new-postrm`` abort-install *old-version* *new-version*
+| ``new-postrm`` abort-upgrade *old-version* *new-version*
 
 Called before unpacking the new package as part of the error
 handling of ``preinst`` failures. May assume the same state as
@@ -229,7 +229,7 @@ These are the "error unwind" calls listed below.
 
.. parsed-literal::
 
-   new-prerm failed-upgrade *old-version*
+   new-prerm failed-upgrade *old-version* *new-version*
 
If this works, the upgrade continues. If this does not work, the
error unwind:
@@ -305,13 +305,13 @@ These are the "error unwind" calls listed below.
 
.. parsed-literal::
 
-   *new-preinst* upgrade *old-version*
+   *new-preinst* upgrade *old-version* *new-version*
 
If this fails, we call:
 
.. parsed-literal::
 
-   *new-postrm* abort-upgrade *old-version*
+   *new-postrm* abort-upgrade *old-version* *new-version*
 
i.  If that works, then
 
@@ -331,13 +331,13 @@ These are the "error unwind" calls listed below.
 
.. parsed-literal::
 
-   *new-preinst* install *old-version*
+   *new-preinst* install *old-version* *new-version*
 
Error unwind:
 
.. 

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

[Russ Allbery]

Cyril Brulebois  writes:
> Russ Allbery  (2022-09-19):

>> but I suspect that, to the extent that this is a Policy issue, the problem
>> was that a source package is not itself a udeb and therefore it wasn't clear
>> whether Policy applies to source packages that only produce udebs.  My gut
>> feeling is that it should not: the whole point of udebs is that they get to
>> break the rules.
>> 
>> So, in addition to saying that Standards-Version is generally not used for
>> udebs or for source packages that only build udebs (I would use wording
>> like that rather than "required" since Policy puts no requirements on
>> udebs at all), maybe we should add to this paragraph in 1.1 (Scopes):
>> 
>> 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.
>> 
>> That could be as simple as saying "udebs (...) and source packages that
>> produce only udebs do not comply"

> Looks good to me, thanks!

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.
 
 .. [#]
Informally, the criteria used for inclusion is that the material meet

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

Re: Idea for Policy expert reviewer list

[Russ Allbery]

Sean Whitton  writes:

> I think this is a nice idea, and could help a lot with our bugs.  I
> think that we should do it in the lightest-weight way that we can.  That
> is, let's

> 1) have the list

> 2) write down in the README that we'll CC people at the point that
>things have got sufficiently concrete, as you say

> 3) announce on d-d-a that we would like people to put themselves on the
>list / ask us to put them on the list.

> Seems to me this could achieve everything you want to achieve without
> introducing any serious bookkeeping work for anyone.  (Additionally, not
> sure why this would need to go to debian-devel -- seems like a Policy
> team-internal thing.)

Yes, good point, I'm not sure why I was thinking that we needed to discuss
it on debian-devel first.

Okay, not sure when I will get around to kicking it off, but I have added
it to my to-do list.

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

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

[Russ Allbery]

Charles Plessy  writes:

> I disagree with this point of view.  In my own case I had to take a
> dictionary to learn what a stanza is, while the word paragraph is surely
> know at least to anybody who studied English in a classroom.

> In my own field, (molecular biology) we (or at least some of us) are
> putting some effort to eliminate jargon and use simple words that makes
> written documents more accessible to the public.  This is why I prefered
> paragraph to stanza when working on the specification.

This is a very valid point, and I appreciate you bringing this up!

My personal opinion is that I don't think jargon is necessarily good or
bad.  It has advantages and drawbacks.

One drawback that you're correctly pointing out is accessibility: jargon
can make things that would otherwise be comprehensible harder to
understand.  It can also be off-putting and alienating to people, and thus
make it harder for them to get involved in a shared project.

The advantage of jargon, and the reason why jargon exists and why humans
keep inventing it, is that it's precise.  You don't need as much context
to disambiguate what a sentence may be talking about.  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.  In some
contexts, precision doesn't matter, but Debian Policy is one place where
we should try to be precise.

Stanza has the significant drawback that it's dictionary definition is
specific to poetry.  In poetry, it's a close analog to how we're using it,
but that does make it somewhat obscure.  It does have the minor advantage
of being terminology that was already in use for exactly this construction
in deb822 files.

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.

> If I were to redo such a specification from scratch, I would ask
> non-European language speakers their opinion too.

I'm definitely interested in that opinion from anyone who is listening in!

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

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

[Charles Plessy]

Hi all,

while I do not want to pull the handbrake I would like to add my
minority opinion to that change:

Le Tue, Sep 20, 2022 at 04:11:43PM +, Russ Allbery (@rra) a écrit :
> 
> The «stanza» name is a commonly used and understood term when referring
> to deb822 blocks. Although «paragraph» is commonly used it has the
> problem of being confusing as it then makes it hard to distinguish
> actual text paragraphs in prose, while «stanza» is a very specific
> term that is not applied anywhere else in the deb822 context, so it's
> always more clear and specific.

I disagree with this point of view.  In my own case I had to take a
dictionary to learn what a stanza is, while the word paragraph is surely
know at least to anybody who studied English in a classroom.

In my own field, (molecular biology) we (or at least some of us) are
putting some effort to eliminate jargon and use simple words that makes
written documents more accessible to the public.  This is why I prefered
paragraph to stanza when working on the specification.

If I were to redo such a specification from scratch, I would ask
non-European language speakers their opinion too.

Have a nice day,

-- 
Charles

Re: Idea for Policy expert reviewer list

[Sean Whitton]

Hello,

On Tue 20 Sep 2022 at 09:39AM -07, Russ Allbery wrote:

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

I think this is a nice idea, and could help a lot with our bugs.  I
think that we should do it in the lightest-weight way that we can.  That
is, let's

1) have the list

2) write down in the README that we'll CC people at the point that
   things have got sufficiently concrete, as you say

3) announce on d-d-a that we would like people to put themselves on the
   list / ask us to put them on the list.

Seems to me this could achieve everything you want to achieve without
introducing any serious bookkeeping work for anyone.  (Additionally, not
sure why this would need to go to debian-devel -- seems like a Policy
team-internal thing.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Mon 19 Sep 2022 at 09:29PM -07, Russ Allbery wrote:

> So, in addition to saying that Standards-Version is generally not used for
> udebs or for source packages that only build udebs (I would use wording
> like that rather than "required" since Policy puts no requirements on
> udebs at all), maybe we should add to this paragraph in 1.1 (Scopes):
>
> 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.
>
> That could be as simple as saying "udebs (...) and source packages that
> produce only udebs do not comply"

Sounds good to me.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Idea for Policy expert reviewer list

[Russ Allbery]

I had an idea this morning while working through the Policy backlog and
wanted to see if others think it's worth pursuing.

One of the challenges of some Policy changes is that there can be subtle
nuances that aren't obvious.  We currently rely on the seconding process
to ensure that at least a few people have had eyes on any given change,
but that's at the mercy of whoever happens to be reading debian-policy.
Thankfully, many long-time Debian contributors have been willing to keep
up with the list, but Debian is busy and traffic can be bursty and that
may not always be the best use of their time.

The IETF has a concept of expert review for certain types of changes, and
the Linux kernel and other projects use subsystem maintainers to route
patch reviews to appropriate people.  I'm wondering if Policy would
benefit from a similar sort of concept: maintaining a list of expert
reviewers.

The idea would look something like this:

* We would keep a list of general Policy areas and a corresponding list of
  Debian experts in that area in a file in the debian-policy source
  package (but not part of the binary package or published on the web
  site).  Or we put it in the wiki, but I'm trying to reduce the number of
  places people's email addresses get published for spamming purposes
  (probably futilely).

* If something in that area comes up, the Debian Policy Editors would cc
  the experts in that area once there's a concrete proposal or patch
  that's ready for review.

* Anyone who feels like they have deep expertise in an area of Debian and
  wants to be listed can just ask us and we'll add them.

This wouldn't be a blocking review necessarily, since people are busy and
sometimes there are expert disagreements that we still have to sort out.
But the point would be to make sure the people with the highest-quality
input would have an opportunity to see any change.

Obviously this wouldn't be necessary for areas of Policy work that mostly
correspond to a single package.  In those cases (libc, for example), we
should just copy the package maintainers.  But there are a lot of fuzzier
areas, like bootstrapping, the maintainer script execution model, shared
library dependencies, the Perl policy, debconf, and so forth where I know
there are domain experts in Debian but we don't have a systematic way of
involving them in patch review.

If all those folks are happy to read debian-policy, this is sort of
pointless.  I'm guessing that's not the case, but I don't really know.

Guillem can also decide if he wants to be an expert reviewer on most of
Policy.  :)

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

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

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Russ Allbery]

Guillem Jover  writes:

> Ok, I've prepared the attached incremental patch, which only switches
> from paragraph(s) to stanza(s) all over the place.

Thanks, applied.

> I've updated all the specs for consistency. I've updated the footnote to
> swap the preference and to mention paragraph is now discouraged
> nomenclature. I've also updated all «id»s out of consistency, which
> might break links, so I can revert that if you'd prefer.

It looks like it was primarily in the copyright-format specification.  I
think that's fine; we haven't historically tried hard to preserve anchors,
and if we ever did, we should probably use some scheme to assign stable
anchors rather than using the text of the heading.

> And I've preserved the (upper) casing for one of the titles
> (“Stand-alone License Stanza”, although that was not consistent with the
> other titles, such as “Files stanza”, I'm happy to lower case that one).

I personally have been convinced by a co-worker who did the research that
one should stop using title-casing in technical documents, since it's
mostly a US convention, US readers don't mind lowercase, and title-casing
can look weird to European readers.  But that's a fix for another day.

> I've gone one by one, but please review carefully as I might have
> perhaps switched in excess!

Reviewed, and also checked for remaining uses of "paragraph."  Everything
looked good.

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

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

[Russ Allbery]

Holger Levsen  writes:
> On Mon, Sep 19, 2022 at 09:29:36PM -0700, Russ Allbery wrote:

>> I'm fine with this change, but as Sam points out, the deeper point here
>> is that Policy doesn't apply to udebs.  This is the whole point of
>> udebs.

> When you say it like this, it sounds to strong to me, if it were written in
> -policy.

> .udebs are allowed to break some rules, but not all. it's not ok to put
> Microsoft Word in an udeb in main. there are many other rules .debs need to
> comply to.

Yeah, apologies, this is just shorthand for "udebs are allowed to ignore
the technical bits of Policy that don't work for them."  Not that they can
do absolutely anything they want.  :)

>> 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.
>  
> this sounds good to me.

Okay, great, thanks.  I'll try to put together a proposed patch soon.

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

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

[Cyril Brulebois]

Russ Allbery  (2022-09-19):
> I'm fine with this change, but as Sam points out, the deeper point here is
> that Policy doesn't apply to udebs.  This is the whole point of udebs.
> 
> I didn't go back and read the history of this bug

Neither did I (I think I was asking for something quite easy and simple,
to make our lives easier, but it kind of blew up and I stepped backward).

> but I suspect that, to the extent that this is a Policy issue, the problem
> was that a source package is not itself a udeb and therefore it wasn't clear
> whether Policy applies to source packages that only produce udebs.  My gut
> feeling is that it should not: the whole point of udebs is that they get to
> break the rules.
> 
> So, in addition to saying that Standards-Version is generally not used for
> udebs or for source packages that only build udebs (I would use wording
> like that rather than "required" since Policy puts no requirements on
> udebs at all), maybe we should add to this paragraph in 1.1 (Scopes):
> 
> 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.
> 
> That could be as simple as saying "udebs (...) and source packages that
> produce only udebs do not comply"

Looks good to me, thanks!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[Holger Levsen]

On Mon, Sep 19, 2022 at 09:29:36PM -0700, Russ Allbery wrote:
> I'm fine with this change, but as Sam points out, the deeper point here is
> that Policy doesn't apply to udebs.  This is the whole point of udebs.

When you say it like this, it sounds to strong to me, if it were written in
-policy.

.udebs are allowed to break some rules, but not all. it's not ok to put
Microsoft Word in an udeb in main. there are many other rules .debs need to
comply to.

> 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.
 
this sounds good to me.


-- 
cheers,
Holger

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

Where will your kids go when they become climate refugees?


signature.asc
Description: PGP signature