Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Hideki Yamane  writes:
> Russ Allbery  wrote:

>> Licenses will be included in common-licenses if they meet all of the
>> following criteria:

>  How about just pointing SPDX licenses URL for whole license text and
>  lists DFSG-free licenses from that? (but yes, we should adjust short
>  name of licenses for DEP-5 and SPDX for it).

Can we do this legally?  If we can, it certainly has substantial merits,
but I'm not sure that this satisfies the requirement in a lot of licenses
to distribute a copy of the license along with the work.  Some licenses
may allow that to be provided as a URL, but I don't think they all do
(which makes sense since people may receive Debian on physical media and
not have Internet access).

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

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Enrico Zini]

On Sat, Sep 09, 2023 at 08:35:27PM -0700, Russ Allbery wrote:

> Licenses will be included in common-licenses if they meet all of the
> following criteria:
> 
> * The license is DFSG-free.
> * Exactly the same license wording is used by all works covered by it.
> * The license applies to at least 100 source packages in Debian.
> * The license text is longer than 25 lines.

I like this. I'd say that even if a license is shorter than 25 lines I'd
appreciate to be able to link to it instead of copypasting it.

I like to be able to fill the license field with a value, after checking
that the upstream license didn't diverge from what it looks like. I'd
love to use SPDX IDs there, for example. In an ideal world, I'd like to
autofill debian/copyright with SPDX IDs from upstream metadata. Having a
link to a file goes closer to having a declarative license ID.

In general the less bytes I have to maintain in debian/* the happier I
am, and as a personal aesthetic sense I feel like the less bytes we all
have to maintain in debian/* the less is our collective maintenance
burden.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 05:35:27)
> In order to structure the discussion and prod people into thinking about
> the implications, I will make the following straw man proposal.  This is
> what I would do if the decision was entirely up to me:
> 
> Licenses will be included in common-licenses if they meet all of the
> following criteria:
> 
> * The license is DFSG-free.
> * Exactly the same license wording is used by all works covered by it.
> * The license applies to at least 100 source packages in Debian.
> * The license text is longer than 25 lines.

I fully support the above proposed criteria, and appreciate your
initiative to have this conversation.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, tagging 904608 ...

[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'

> tags 904608 = wontfix
Bug #904608 {Done: Russ Allbery } [debian-policy] Include 
upstream metadata spec in Policy
Removed tag(s) moreinfo.
> tags 830913 = wontfix
Bug #830913 {Done: Russ Allbery } [debian-policy] 
debian-policy: Allow amd64 systems without /lib64
Removed tag(s) moreinfo.
> tags 940234 = wontfix
Bug #940234 {Done: Russ Allbery } [debian-policy] 
debian-policy: add a section about source reproducibility
Removed tag(s) moreinfo.
> usertags 986320 discussion
Usertags were: normative discussion.
Usertags are now: normative discussion.
> thanks
Stopping processing here.

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

Bug#991984: marked as done (Please document minimal environment variable needed for sensible-utils)

[Debian Bug Tracking System]

Your message dated Sat, 09 Sep 2023 21:28:34 -0700
with message-id <87jzsyzm6l@hope.eyrie.org>
and subject line Re: Bug#991984: Please document minimal environment variable 
needed for sensible-utils
has caused the Debian Bug report #991984,
regarding Please document minimal environment variable needed for sensible-utils
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.)


-- 
991984: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991984
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-policy
Version: 4.5.1.0
Severity: important
Control: block 991982 by -1
Control: block 987675 by -1


Dear Maintainer,

For now $env -i sensible-utils, fail due to $HOME and $TERM not set.

I am for now working around HOME not set in sensible-utils core, but posix [1]
documentation does not document really the value that should be set for a
correct behavior of program.

Nevertheless:
- we should expect that PATH is set to a sensible value (note that it depends
of the shell), but nevertheless not setting PATH is not really safe
- HOME may not be set. If set the value may be incorrect (su -)
- TERM may not be set. If set the value may not be correct
- USER may not be set. If set the value may be incorrect (su -)

So I will like to have a footnote saying that sensible-pager/sensible-editor
etc, should test if they work under env -i, and if they do not work fallback to
return 126 (according to shell documentation Command invoked cannot execute),
thus allowing sensible-utils to fallback to vi that is safe and tested under
env -i

Bastien




[1] https://pubs.opengroup.org/onlinepubs/9699919799/
--- End Message ---
--- Begin Message ---
Russ Allbery  writes:

> Policy does not mandate any specific behavior for sensible-editor and
> sensible-pager other than that they will implement the EDITOR and PAGER
> environment variable checking for you.  I think that's best left to the
> maintainer of those programs to decide.

> We also don't expect that the editor or pager invoked following the
> rules in Policy 11.4 (and, by extension, sensible-editor and
> sensible-pager themselves) will work in unusual situations, such as ones
> without standard environment variables set.  We can't: the user is free
> to set EDITOR and PAGER to anything they chose, including programs not
> in Debian.  So you can't really expect any particular behavior from
> whatever EDITOR or PAGER is set to.  Maybe it will fail with a helpful
> error code, maybe it will start and not work but not exit, maybe
> something else entirely will happen.  This is really outside of our
> control.

There was no further discussion of this over the past year, so I'm going
to go ahead and close this bug with the above comment.

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

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

[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 904608 = normative obsolete
Usertags were: obsolete normative.
Usertags are now: obsolete normative.
> usertags 830913 = normative obsolete
Usertags were: normative.
Usertags are now: obsolete normative.
> tags 830913 + wontfix
Bug #830913 {Done: Russ Allbery } [debian-policy] 
debian-policy: Allow amd64 systems without /lib64
Added tag(s) wontfix.
> usertags 940234 = normative obsolete
Usertags were: normative.
Usertags are now: obsolete normative.
> tags 940234 + wontfix
Bug #940234 {Done: Russ Allbery } [debian-policy] 
debian-policy: add a section about source reproducibility
Added tag(s) wontfix.
> usertags 986320 discussion
Usertags were: normative.
Usertags are now: normative discussion.
> usertags 991984 = normative dubious
Usertags were: normative.
Usertags are now: normative dubious.
> tags 991984 + wontfix
Bug #991984 [debian-policy] Please document minimal environment variable needed 
for sensible-utils
Added tag(s) wontfix.
> thanks
Stopping processing here.

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

Bug#940234: marked as done (debian-policy: add a section about source reproducibility)

[Debian Bug Tracking System]

Your message dated Sat, 09 Sep 2023 21:23:52 -0700
with message-id <87o7iazmef@hope.eyrie.org>
and subject line Re: Bug#940234: debian-policy: add a section about source 
reproducibility
has caused the Debian Bug report #940234,
regarding debian-policy: add a section about source reproducibility
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.)


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

There is already a section about reproducibility in the debian-policy,
but it only mentions the binary packages. It might be a good idea to
add a new requirement that repeatedly building the source package in
the same environment produces identical .dsc file modulo the GPG
signature.

I haven't checked how many packages do not fulfill this condition, but
there are for sure packages where the Build-Depends: entry in the dsc
file does not match the debian/control file, as they have been added
manually after the package build. TTBOMK there is nothing preventing
that in the debian policy.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  1.8.5-3

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information
--- End Message ---
--- Begin Message ---
Holger Levsen  writes:

>>> I haven't checked how many packages do not fulfill this condition

> You should definitly do this before asking policy to be changed.
> It's also not really hard, just loop through all source packages,
> download them, rebuild them, compare.

> And you might want to start with just the essential set. 

> and, TBH, I'm pretty sure very few source packages can be rebuild 
> reproducible. Proove me wrong! :)

It's been about a year since the last response on this bug, and I think
the most recent round of responses were to someone who quoted the entire
original bug report without adding any new content.  I don't think we can
do anything with this bug on the Policy side until someone confirms that
source package reproducibility is viable, so I'm going to close this bug
for the time being.

If someone wants to do the work to confirm that, please do open a new bug
so that we can document it in Policy.

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

Bug#830913: marked as done (debian-policy: Allow amd64 systems without /lib64)

[Debian Bug Tracking System]

Your message dated Sat, 09 Sep 2023 21:18:37 -0700
with message-id <87sf7mzmn6@hope.eyrie.org>
and subject line Re: Bug#830913: debian-policy: Allow amd64 systems without 
/lib64
has caused the Debian Bug report #830913,
regarding debian-policy: Allow amd64 systems without /lib64
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.)


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

Some amd64 systems do not have /lib64, although they can run programs
with the interpreter set to /lib64/ld-linux-x86-64.so.2 . It would be
nice if Debian could allow such systems. In section 9.1.1, where it
says:

The execution time linker/loader, ld*, must still be made
available in the existing location under /lib or /lib64

"must" should be "should".


smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
--- Begin Message ---
Russ Allbery  writes:
> Javier Serrano Polo  writes:

>> Some amd64 systems do not have /lib64, although they can run programs
>> with the interpreter set to /lib64/ld-linux-x86-64.so.2 . It would be
>> nice if Debian could allow such systems. In section 9.1.1, where it
>> says:

>> The execution time linker/loader, ld*, must still be made
>> available in the existing location under /lib or /lib64

>> "must" should be "should".

> You reported the above bug six years ago, and it looks like it never
> received a reply.  I'm sorry about that!

> I'm confused by this bug report, though.  What does "some amd64 systems"
> mean in this context?  It looks to me like the amd64 libc6 package
> provides /lib64/ld-linux-x86-64.so.2, so a Debian amd64 system would
> satisfy this.  Is there some alternate libc6 package available in Debian
> that does things differently?  Or are you thinking of some sort of
> container or other type of restricted system?

> Also, in this case, how does this work?  Is the path somehow remapped at
> the kernel level?  (If so, I'm wondering if that would qualify as "made
> available" for the purposes of Policy anyway.)

It's now been about a year and it looks like this message didn't get a
reply, so I'm going to go ahead and close this bug because I don't think
we have enough information to act on it.  If there are more details about
my questions above, feel free to open it.

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

Bug#904608: marked as done (Include upstream metadata spec in Policy)

[Debian Bug Tracking System]

Your message dated Sat, 09 Sep 2023 21:12:48 -0700
with message-id <87wmwyzmwv.fsf...@hope.eyrie.org>
and subject line Re: Bug#904608: Include upstream metadata spec in Policy
has caused the Debian Bug report #904608,
regarding Include upstream metadata spec in Policy
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.)


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

Hi,

Some tools, like git-buildpackage, can support merging an upstream's
version history into Debian packaging repositories. This enables more
rich usage of (D)VCS when packaging - for example `git blame' works
properly.

Currently there's no canonical place to specify where upstream's VCS is
located so people have to set this up manually themselves. If there were
such a place, it would be possible for tools like `gbp clone' to
configure the VCS to know about the upstream history when checking out a
packaging repository.

The request here is to ask whether this would be suitable for
debian/control, along the lines of the Vcs-* fields specified in 5.6.26
and the Homepage field in 5.6.23.

If so, I'd be happy to propose wording for policy. I'm not set on any
particular name, so please feel free to weigh in on that if you'd like.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
--- End Message ---
--- Begin Message ---
Sean Whitton  writes:
> On Thu 26 Jul 2018 at 09:21AM +0100, Iain Lane wrote:

>> However, I'm not very keen on the extra work that would be required to
>> transfer that wiki page into policy as opposed to specifying an extra
>> field.
>>
>> Do you agree that policy should recommend such a location and is the
>> path to this recommendation, in your opinion, a ratification of the
>> UpstreamMetadata page or something like it?

> No-one needs to do that extra work anytime soon.  Policy lags best
> practices.  The fact that debian/upstream/metadata is already being used
> to store a URI to the upstream repository for a large number of packages
> counts as standardisation, in Debian Policy terms.  You can refer to it
> in tools that you write.

> We should eventually move the upstream metadata spec into Policy.  I'm
> retitling the bug, but also tagging it as moreinfo.  The moreinfo tag is
> used to indicate that it is not clear that the bug against debian-policy
> is actionable.

> What is currently unclear is whether the upstream metadata spec is
> sufficiently mature to go into Policy.  We need to hear from those
> involved with that spec that it's sufficiently mature to go into Policy.
> If it's sufficiently mature, such that all that's needed is writing a
> patch to Policy, we can remove the moreinfo tag and leave the bug open,
> awaiting someone driving its inclusion in Policy.  If the spec is not
> ready to go into Policy, then there is no Policy work to be done, and we
> should close the bug.

It's now five years later and there hasn't been any forward progress on
including the upstream metadata spec into Policy or confirming whether it
is stable.  There has also been some disagreement with this idea from
Guillem, who would like the data in a format that dpkg can read rather
than YAML (which I assume he is unwilling to add as a dpkg dependency),
and from Ian, who doesn't like the YAML format.

I'm therefore going to conclude that we don't have support or energy for
making a Policy change at this time and am going to close this bug.
Someone who feels that the upstream metadata spec should be adopted by
Policy and wants to push that forward is free to open a new bug to pursue
that.

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

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

[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 904608 obsolete
Usertags were: normative.
Usertags are now: obsolete normative.
> tags 904608 + wontfix
Bug #904608 [debian-policy] Include upstream metadata spec in Policy
Added tag(s) wontfix.
> usertags 1030382 normative dubious
There were no usertags set.
Usertags are now: dubious normative.
> tags 1030382 + wontfix
Bug #1030382 {Done: Russ Allbery } [debian-policy] encourage 
Vcs-Git over other Vcs-* headers
Added tag(s) wontfix.
> thanks
Stopping processing here.

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

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Hello everyone,

I come seeking your opinions.  Please cc 885...@bugs.debian.org on replies
so that we can accumulate this discussion in a Debian Policy bug.

One of the responsibilities of the Policy Editors is to determine which
licenses should be included in /usr/share/common-licenses, and thus do not
have to be reproduced in the copyright file of every package that use
them.  We have never had a clear criteria for this.  We need one, so that
we can advertise a clear and transparent policy for inclusion without
having the conversation from first principles for each new license.

I was the one who made the last few decisions, and I based the decision
largely on the number of binary packages in Debian using the license.
When I was doing this, I set a fairly high threshold (more packages than
the least popular package currently in /usr/share/common-licenses, which
historically has been GFDL-1.3 although it now appears to be MPL-1.1).  No
one was entirely satisfied with that criteria, including me.

I have the following questions:

1. What criteria (besides the obvious one of being a DFSG-free license)
   should we apply when deciding what licenses to include?  Number of
   packages?  Length?  How positive we feel towards the license?  Some
   combination of these things?  Please be specific.

2. If we use number of packages as a criteria, what should the threshold
   be?  I have appended to the bottom of this message the current output
   of my ad-hoc license-count tool run against the current archive so that
   you have a feeling for how many packages use various licenses.

3. If we use number of packages, should that be source packages or binary
   packages?  Source packages represent maintainer effort; binary packages
   represent disk clutter.

4. Should there be a length cutoff for licenses, such that we do not
   include in /usr/share/common-licenses any license shorter than some
   number of lines or bytes?  The justification would be that telling
   people to go look elsewhere for the license has some inherent overhead
   and annoyance when they discover that the license is all of ten lines
   and could have just been included in the copyright file.

5. Should we exclude licenses that contain text that all or most users of
   the license customize when they use it?  For example, the existing
   /usr/share/common-licenses/BSD contains the clause:

  3. Neither the name of the University nor the names of its
 contributors may be used to endorse or promote products derived
 from this software without specific prior written permission.

   which users of this specific license usually change to instead include
   the name of their organization, or their name, or something else.  Full
   disclosure: it will be very hard to convince me that licenses used this
   way should be included in common-licenses, since I believe it is
   technically incorrect to omit a license and point to the
   common-licenses version when the provisions of the common-licenses
   version are different in detail due to naming different people or
   requiring or prohibiting mentioning of different names as endorsements.

Here are various concerns that people have had in this area in the past.
I'm neither indicating agreement nor disagreement with any of these
points, only listing them to provoke thought about some of the things
people have raised before.

* Including long legal texts in debian/copyright, particularly if one
  wants to format them for copyright-format, is tedious and annoying and
  doesn't benefit our users in any significant way, and therefore we
  should include as many licenses as possible in common-licenses to spare
  people that work.

* common-licenses consumes disk space on every installed Debian system of
  any size, and therefore should be kept small to avoid wasting system
  resources.

* Every appproved DFSG license should be included in common-licenses so
  that it serves as a repository of licenses the project has approved.

* Including a license in common-licenses implies that the project approves
  of that license, and therefore licenses such as the LaTeX Project Public
  License 1.0, which requires renaming derived works, should not be
  included even though DFSG #4 grudgingly allows for this type of license
  term.

* All licenses explicitly mentioned in the Debian Free Software Guidelines
  should be present in common-licenses (as justification for including the
  BSD license even though the current text is specific to the Regents of
  the University of California).

In order to structure the discussion and prod people into thinking about
the implications, I will make the following straw man proposal.  This is
what I would do if the decision was entirely up to me:

Licenses will be included in common-licenses if they meet all of the
following criteria:

* The license is DFSG-free.
* Exactly the same license wording is used by all works covered by it.
* The 

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

[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 981406 normative discussion
There were no usertags set.
Usertags are now: discussion normative.
> severity 981406 wishlist
Bug #981406 [debian-policy] define "makefile" as a GNU Make-compatible 
makefile; support 'gmake' shebang
Severity set to 'wishlist' from 'minor'
> usertags 1006976 normative proposal
There were no usertags set.
Usertags are now: normative proposal.
> usertags 1049406 normative discussion
There were no usertags set.
Usertags are now: normative discussion.
> usertags 1050221 informative discussion
There were no usertags set.
Usertags are now: informative discussion.
> usertags 1050221 normative discussion
Usertags were: discussion informative.
Usertags are now: discussion normative informative.
> usertags 940234 normative
There were no usertags set.
Usertags are now: normative.
> tags 940234 + moreinfo
Bug #940234 [debian-policy] debian-policy: add a section about source 
reproducibility
Added tag(s) moreinfo.
> usertags 990822 normative
There were no usertags set.
Usertags are now: normative.
> tags 990822 + moreinfo
Bug #990822 [debian-policy] debian-policy: Please document version scheme for 
derivatives
Added tag(s) moreinfo.
> usertags 1004522 normative
There were no usertags set.
Usertags are now: normative.
> tags 1004522 + patch
Bug #1004522 [debian-policy] debian-policy: Proposing new virtual package: 
wayland-session
Added tag(s) patch.
> usertags 1006912 normative
There were no usertags set.
Usertags are now: normative.
> tags 1006912 + patch
Bug #1006912 [debian-policy] is it time to have account deletion in policy?
Added tag(s) patch.
> usertags 1026231 normative discussion
There were no usertags set.
Usertags are now: normative discussion.
> tags 945269 + patch
Bug #945269 [debian-policy] debian-policy: packages should use tmpfiles.d(5) to 
create directories below /var
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1004522: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004522
1006912: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006912
1026231: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026231
940234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940234
945269: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269
981406: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981406
990822: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990822
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Luca Boccassi  writes:

> Sure, updated as suggested.

I have a bunch of minor wording fixes that I'd want to make at this before
merging, but that should be straightforward to do.  Before I invest the
time in that, I want to check the opinions of everyone else following
along and see if the semantics of Luca's change have general approval.

Could folks take a look at this patch and see if the basic gist of it is
something that they would second (or, for that matter, is something they
would object to)?  I think I would second it (with wording adjustments),
with one caveat mentioned below.  The whole thing is at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#295

Luca, am I right that service directories are specific to, well, services?
If so, what would you think of moving them to Policy 9.3 alongside the
other discussion of systemd units?  They feel out of place here, since
packages that do not use services cannot use this functionality, and
there's already a statement in the tmpfiles.d section pointing to them as
more appropriate for services.

> +Packages might need additional files or directories to implement their
> +functionality. Directories that are located under ``/var/`` or
> +``/etc/``, and files that are located under ``/var/``, should not be
> +created manually via maintainer scripts, but instead be declaratively
> +defined via the `tmpfiles.d
> +`_
> +interface.  Files and directories under ephemeral filesystems such as
> +``/tmp/`` may also be created and managed via ``tmpfiles.d`` snippets.

I understand the empty directory part, but I don't believe "files that are
located under /var" is correct unless you specifically mean *empty* files
(and even then, I'm not clear on precisely when this would be needed).
For example, /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package
maintainer script, and I can see no possible way that action could (or
should) be handled by the tmpfiles.d mechanism.

What am I missing?

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

Bug#1030382: marked as done (encourage Vcs-Git over other Vcs-* headers)

[Debian Bug Tracking System]

Your message dated Sat, 09 Sep 2023 19:35:06 -0700
with message-id <87a5tu21t1@hope.eyrie.org>
and subject line Re: Bug#1030382: encourage Vcs-Git over other Vcs-* headers
has caused the Debian Bug report #1030382,
regarding encourage Vcs-Git over other Vcs-* headers
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.)


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

Policy currently describes Vcs-* headers as something optional, but stops to
endorse a particular Vcs.

At this point, it seems uncontroversial to encourage use of Vcs-Git
specifically here. Apart from technical arguments, it's the vcs that the
majority of packages in the archive uses - and thus will have the better
tooling, less of a learning curve for other contributors, etc.

There are very few holdouts of other vcses in the archive. I count 62
(ignoring those with an alioth URL):

 * 26 on Svn
 * 3 on Cvs
 * 4 on Hg (2 are hg/hg-buildpackage)
 * 39 on bzr (half of these are actually bzr and related packages, which I 
maintain)

Cheers,

Jelmer

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  5.3.0-3

Versions of packages debian-policy suggests:
pn  doc-base  
--- End Message ---
--- Begin Message ---
Jelmer Vernooij  writes:

> I've created a PR for devref -
> https://salsa.debian.org/debian/developers-reference/-/merge_requests/41

> Are you saying that it doesn't belong in policy because it'd be a
> recommendation rather than a must/should (at this point?), or because
> it's more about the workflow inside of Debian than package contents?

Policy only documents the contents of source and binary packages and a few
related topics like the archive structure and the various control files
that come along with packages.  How packages are maintained is, so far at
least, mostly outside the scope of Policy, which includes making concrete
recommendations about version control systems, forges, workflows, etc.

Therefore, the Developers Reference is the right spot for this.  Since
that has been merged, I'm going to close out this Policy bug.

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

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Russ Allbery  writes:

> -If a service unit is not present, ``systemd`` uses dependency information
> -contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide
> -which scripts to run and in which order.  The ``sysv-rc`` runlevel system
> -for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which
> -scripts to run and in which order at boot time and when the init state (or
> -"runlevel") is changed.  See the ``README.runlevels`` file shipped with
> -``sysv-rc`` for implementation details.  Other alternatives might exist.
> +``systemd`` uses dependency and ordering information contained within the
> ++enabled unit files to decide which services to run and in which order.
> +The ``sysv-rc`` runlevel system for ``sysvinit`` uses the same symlinks in
> +``/etc/rcn.d`` to decide which scripts to run and in which order at boot
> +time and when the init state (or "runlevel") is changed.  See the
> +``README.runlevels`` file shipped with ``sysv-rc`` for implementation
> +details.  Other alternatives might exist.

And of course I have to post the diff to see the bugs.  The part that says
"uses the same symlinks" should now say "uses symlinks".

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

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Luca Boccassi  writes:

> systemd upstream will drop support for the transitional sysv generator
> in the near future. The transition is long finished, it's been at least
> a decade, and it's time for the tail of packages still shipping only
> init scripts but not units to be updated.

> Tentatively this should happen within Trixie's development cycle. Of
> course it's free software and generators are not that difficult to
> maintain, so if someone wanted to lift the sysv generator out of the
> systemd repository and adapt it to be a standalone binary there's
> nothing stopping them. But I wouldn't want the systemd package to depend
> on such a backward compat tool, so packages needing this hyptothetical
> package should depend explicitly on it. This is just mentioned for
> completeness, it's been at least a decade and writing a unit file is
> beyond trivial so there shouldn't be any issue adding the few remaining
> ones.

The mass bug filing happened, and although there were some objections on
debian-devel, I don't think any of them were blocking.  Specifically, I
did not see anyone present a concrete plan for how to keep the systemd
unit generator or some equivalent alive, and given that systemd upstream
is dropping support for this feature, I believe that's the only way for
this change to not be effective mandatory.

Therefore, I think the time is ripe to proceed with this Policy change.

I took a detailed look at this part of Policy today, and the whole system
service section needs serious work.  I believe the instructions it
currently provides for constructing package maintainer scripts won't
actually work with a current Debian system, and most Debian packages are
technically violating the current Policy because it hasn't been updated
for how systemd units work today.  I started on overhauling that section,
but it became clear that this is going to be a larger project with some
potentially controversial decisions, so I'm going to open a new bug about
that so that we don't block this change on that work.

I made the following changes to your last diff:

* Move the "should" about integrating with service management to the
  parent section.

* Explicitly say that systemd is the default init system and service
  manager (it feels like we should say this somewhere, and I don't think
  we already do).

* Add an explicit exception for packages intended only to support
  alternate init systems.  (As an obvious example, sysvinit isn't going to
  ship a systemd unit, nor should it.)

* Delete the paragraph suggesting that packages without systemd units
  should write an init script, since this will no longer accomplish the
  goal of getting that system service to work with systemd and therefore
  no longer seems to serve a purpose.

Here is what I came up with.  I think it is ready for seconds or
objections.

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

>From 474a9f4c74bc2c3a1d162de33e377a3585e641af Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Sat, 9 Sep 2023 18:39:16 -0700
Subject: [PATCH] systemd unit files are now a must

systemd is dropping support for the generator that allows it to
automatically create units for init scripts. As a result, all
packages that want to integrate with systemd service management
must start shipping systemd units.

State that arranging for services to be automatically started or
stopped is a should, but if the package wishes to do that, a
systemd service unit is a must unless the package is only intended
for use with alternate init systems. Avoid saying that systemd uses
/etc/rcn.d links to determine service ordering.
---
 policy/ch-opersys.rst | 35 ---
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 207b3c0..bee16f2 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -323,20 +323,25 @@ which try to write to a home directory will fail to build.
 Starting system services
 
 
+Debian packages that provide system services should arrange for those
+services to be automatically started and stopped by the init system or
+service manager.  This section describes how that is done.
+
 .. _s-services-intro:
 
 Introduction
 
 
-Packages that include system services should include ``systemd`` service
-units to start or stop those services.  See :manpage:`systemd.service(5)`
-for details on the syntax of a service unit file.  In the common case that
-a package includes a single system service, the service unit should have
-the same name as the package plus the ``.service`` extension.
+The default init system and service manager in Debian is ``systemd``.
+Packages that wish to automatically start and stop system services must
+include ``systemd`` service units to do so, unless the service is only
+intended for use on systems running alternate init systems.  See
+:manpage:`systemd.service(5)` for 

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Russ Allbery]

Package: debian-policy
Version: 4.6.2.0
Severity: important
X-Debbugs-Cc: r...@debian.org

As part of reviewing #1039102, I took a detailed look at Policy 9.3
on system services and realized that it is largely obsolete and is
not followed by most Debian packages that provide system services.
Specifically:

* There is no real documentation of systemd units except in the
  introduction, and most of the section describes init scripts as
  if they were the only way to start a service.

* All packages are told they must use update-rc.d, but systemd units
  no longer use update-rc.d.  They instead use deb-systemd-helper in
  ways that are not documented in Policy and I believe are maintained
  primarily in debhelper.

* All packages are told they should use invoke-rc.d, but systemd units
  no longer use invoke-rc.d.  They instead use deb-systemd-invoke,
  which also supports the policy-rc.d interface.

* The policy-rc.d interface is undocumented.

This part of Policy is also a bit of a mess of deleted sections due to
a desire to avoid section renumbering.

I started a rewrite of this section, but quickly ran into the question
of how to document the correct invocations of deb-systemd-helper and
deb-systemd-invoke.  After thinking about this for a while, the
conclusion I reached was that documenting this in Policy is both extra
make-work that we do not have the resources to keep up with, and serves
no real purpose for nearly every reader of Debian.  debhelper is already
maintaining the correct code to set up systemd services in close
cooperation with the systemd and init-system-helpers maintainers, that
code contains temporary workarounds and other fixes that Policy is not
going to keep up with, and it's hard to justify duplicating that work in
a Policy statement.

I therefore would like to propose a first: I think Policy should simply
say that any package that provides a system service should use debhelper
and rely on dh_installsystemd to put the appropriate commands in its
maintainer scripts.  (We can then discuss whether we should do the same
for init scripts and dh_installinit, although its stanzas are simpler.)

Previously we have tried to avoid doing this, and have maintained the
principle that debhelper is simply an *implementation* of Policy, and it
still falls to Policy to describe what debhelper should do.  However, I
think it is now abundantly obvious that debhelper has considerably more
development resources available to it than Policy has writers, debhelper
developers are quite rightfully not waiting for things to be added to
Policy before they can be implemented, and essentially every Debian
package that does anything non-trivial uses debhelper now.  I also don't
see any truly useful purpose served by dumping a wad of shell code into
Policy that essentially no one will use because it's what debhelper would
add for them.

I have some other questions about the rewrite of these sections (such as
how hard we should try to retain section numbering), but I think we should
resolve this question first, since it has dramatic effects on what text
we should write.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  5.3.0-7

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

Bug#1050322: Partial versus complete replacement of a package by another

[Russ Allbery]

julien.pu...@gmail.com writes:

> Oh. I think I had two problems:
> (1) thinking "Replaces" meant "replaces" ;
> (2) thinking d/control controlled packages.

> Let me try to see if I'm getting at something:

> (*) Replaces doesn't really mean "can be used in place of"
> -- that would be expressed with Breaks+Provides.

> (*) Replaces shouldn't come without Breaks, but doesn't imply it
> so we have to put in both (why?).

Yes, this is a good question.  I recently was confused about this myself
despite having worked on Debian and maintained Policy and, at times,
Lintian for years, which implies that we don't do a very good job of
documenting the ins and outs of this.

https://lists.debian.org/debian-devel/2023/06/msg00354.html is the best
explanation of this that I've seen.  The short summary is that the one
case where Breaks is not required is if the package with Replaces also
depends on a new version of the package that it is replacing.  This
prevents the scenario described in the footnote.

The other thing that's worth noting is that sometimes you want Breaks and
sometimes you want Conflicts, and both Breaks and Conflicts are useful
without Replaces for other reasons, so none of them can really imply any
of the others.

I also saw your other bug (#1050221) about promoting that footnote to the
main text.  That's a partial fix, but I think we should include some
portion of Helmut's explanation directly in Policy as well.  (We sort of
say this, but we're not nearly as explicit about it as we could be, and we
don't use normative language.)

> (*) In 7.6.1's example, what happens if the system has foo 1.2-2 and
> the user tries to install foo-data 1.2-3? Do we end up with foo 1.2-2
> and foo-data 1.2-3 unpacked and apt/dpkg complaining it can't configure
> them or does it refuse with a clear error message?

It refuses to begin the operation because foo-data 1.2-3 breaks foo 1.2-2
and foo 1.2-2 is currently configured.  foo 1.2-2 has to be unconfigured
first before the installation of foo-data 1.2-3 can procede.  (This is
documented in Policy 7.3 where Breaks is discussed.)

What normally happens is that users use apt rather than dpkg directly.  I
believe apt will force an upgrade of foo because it sees that it is broken
by foo-data and will not allow installation of foo-data without either
upgrading or removing foo.  (dpkg does not do this because dpkg in general
operates on only the packages it's told to operate on and doesn't expand
the scope of one invocation to change other packages.)

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

Bug#1024367: In 4.9.1, the example uses not recommended install -s

[gregor herrmann]

On Sat, 09 Sep 2023 15:16:10 -0700, Russ Allbery wrote:

> I'm therefore going to propose fixing this bug with the following patch,
> which is more aggressive than you propose.
> 
> I think this is informative rather than normative and therefore
> technically doesn't require seconds, but I'll give this some time for
> other people to take a look and talk me out of deleting this section if
> they wish.

Looks good to me.

Cheers,
gregor 


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Processed: Re: Bug#1031403: debian-policy: missing quotes in sh script example in file policy/ap-pkg-diversions

[Debian Bug Tracking System]

Processing control commands:

> tags -1 pending
Bug #1031403 [debian-policy] debian-policy: missing quotes in sh script example 
in file policy/ap-pkg-diversions
Added tag(s) pending.

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

Bug#1031403: debian-policy: missing quotes in sh script example in file policy/ap-pkg-diversions

[Russ Allbery]

Control: tags -1 pending

Max-Julian Pogner  writes:

> consulting the debian policy manual whether it contains suggestions how
> to best implement diversions (see `man dpkg-divert`), i noticed syntax
> errors in the provided shell script example snippets.

> a patch fixing these typos is attached.

Thanks, applied for the next Policy release.

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

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

[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 949258 normative
There were no usertags set.
Usertags are now: normative.
> tags 949258 + moreinfo
Bug #949258 [debian-policy] debian-policy: Support negated architecture 
specifications in debian/control Architecture field
Added tag(s) moreinfo.
> severity 949258 wishlist
Bug #949258 [debian-policy] debian-policy: Support negated architecture 
specifications in debian/control Architecture field
Severity set to 'wishlist' from 'normal'
> usertags 975637 normative proposal
There were no usertags set.
Usertags are now: proposal normative.
> severity 975637 wishlist
Bug #975637 [debian-policy] debian-policy: deprecate Rules-Requires-Root other 
than "no", "binary-targets" in Debian
Severity set to 'wishlist' from 'normal'
> usertags 983065 normative proposal
There were no usertags set.
Usertags are now: normative proposal.
> severity 983065 wishlist
Bug #983065 [debian-policy] debian-policy: Downgrades are not allowed / Package 
upgrades must have a greater version than previous packages of the same name in 
the same suite
Severity set to 'wishlist' from 'normal'
> usertags 990362 normative proposal
There were no usertags set.
Usertags are now: normative proposal.
> usertags 998165 normative proposal
There were no usertags set.
Usertags are now: proposal normative.
> usertags 1013195 normative discussion
There were no usertags set.
Usertags are now: normative discussion.
> severity 1013195 wishlist
Bug #1013195 [debian-policy] base-files: Please add AGPL-3 license
Severity set to 'wishlist' from 'normal'
> block 1013195 with 885698
Bug #1013195 [debian-policy] base-files: Please add AGPL-3 license
1013195 was not blocked by any bugs.
1013195 was not blocking any bugs.
Added blocking bug(s) of 1013195: 885698
> retitle 924094 Add Artistic-2.0 to common-licenses
Bug #924094 [debian-policy] base-files: Missing Artistic-2.0 in 
/usr/share/common-licenses/
Changed Bug title to 'Add Artistic-2.0 to common-licenses' from 'base-files: 
Missing Artistic-2.0 in /usr/share/common-licenses/'.
> retitle 1013195 Add AGPL-3 to common-licenses
Bug #1013195 [debian-policy] base-files: Please add AGPL-3 license
Changed Bug title to 'Add AGPL-3 to common-licenses' from 'base-files: Please 
add AGPL-3 license'.
> usertags 1021828 packaging
There were no usertags set.
Usertags are now: packaging.
> severity 1021828 minor
Bug #1021828 [debian-policy] debian-policy.info: mysterious anchors in 
cross-references
Severity set to 'minor' from 'normal'
> usertags 1024367 informative
There were no usertags set.
Usertags are now: informative.
> tags 1024367 = patch
Bug #1024367 [debian-policy] In 4.9.1, the example uses not recommended install 
-s
Added tag(s) patch.
> usertags 1027128 informative proposal
There were no usertags set.
Usertags are now: proposal informative.
> usertags 1029831 normative discussion
There were no usertags set.
Usertags are now: normative discussion.
> usertags 1039102 normative
There were no usertags set.
Usertags are now: normative.
> tags 1039102 = patch
Bug #1039102 [debian-policy] debian-policy: make systemd units mandatory for 
packages shipping system services
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1013195: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013195
1021828: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021828
1024367: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024367
1039102: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039102
924094: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924094
949258: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949258
975637: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975637
983065: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983065
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1024367: In 4.9.1, the example uses not recommended install -s

[Russ Allbery]

Enrico Zini  writes:

> Hello, and thank you for maintaining the Policy!

> Policy paragraph 4.9.1 has an example debian/rules which contains these
> lines:

>INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755

>ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
>INSTALL_PROGRAM += -s
>endif

> However, paragraph 10.1 recommends against it:

>It is not recommended to strip binaries by passing the "-s" flag to
>"install", because this fails to remove .comment and .note sections,
>and also prevents the automatic creation of dbgsym binary packages by
>tools like "dh_strip".

> I would personally prefer if the example built on debhelper. If the
> intention is to show what are the expectations at a lower level then
> I wish the example had a comment saying "This snippet serves to explain
> what are the expectations as a lower level. You usually want to use
> debhelper instead"

I looked at this snippet and I think it has worse problems than the use of
install -s.  For example, it predates the existence of dpkg-buildflags,
which would also handle noopt.  I'm also dubious that it serves any useful
purpose given that nearly every package should just use debhelper.  The
typical current Debian packager seems more likely to be confused by this
fragment than aided by it.

I'm therefore going to propose fixing this bug with the following patch,
which is more aggressive than you propose.

I think this is informative rather than normative and therefore
technically doesn't require seconds, but I'll give this some time for
other people to take a look and talk me out of deleting this section if
they wish.

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

>From 409bbd815a946a7bb7b1eea8cab8198c494dd7d4 Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Sat, 9 Sep 2023 15:10:21 -0700
Subject: [PATCH] Remove old Makefile DEB_BUILD_OPTIONS example

The correct way to implement most DEB_BUILD_OPTIONS these days is
to just use debhelper. The detailed Makefile fragment was probably
more confusing than helpful, given that it predates dpkg-buildflags,
uses install -s (which Policy elsewhere recommends against), and
manually does other work debhelper would automate. Replace it with
a note that packaging helper frameworks do much of this work.
---
 policy/ch-source.rst | 35 +++
 1 file changed, 3 insertions(+), 32 deletions(-)

diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 4307e89..b6f2c86 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -588,38 +588,9 @@ The meaning of the following tags has been standardized:
 
 Unknown flags must be ignored by ``debian/rules``.
 
-The following makefile snippet is an example of how one may implement
-the build options; you will probably have to massage this example in
-order to make it work for your package.
-
-.. code-block:: Makefile
-
-CFLAGS = -Wall -g
-INSTALL = install
-INSTALL_FILE= $(INSTALL) -p-o root -g root  -m  644
-INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755
-INSTALL_SCRIPT  = $(INSTALL) -p-o root -g root  -m  755
-INSTALL_DIR = $(INSTALL) -p -d -o root -g root  -m  755
-
-ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
-CFLAGS += -O0
-else
-CFLAGS += -O2
-endif
-ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
-INSTALL_PROGRAM += -s
-endif
-ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-MAKEFLAGS += -j$(NUMJOBS)
-endif
-
-build:
-# ...
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-# Code to run the package test suite.
-endif
-
+Packaging helper frameworks such as debhelper will automatically support
+many of these options without any further work required by the package
+maintainer.
 
 .. _s-debianrules-gainrootapi:
 
-- 
2.40.1

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

[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 924094 normative discussion
There were no usertags set.
Usertags are now: normative discussion.
> severity 924094 wishlist
Bug #924094 [debian-policy] base-files: Missing Artistic-2.0 in 
/usr/share/common-licenses/
Severity set to 'wishlist' from 'normal'
> thanks
Stopping processing here.

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

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

[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 945275 normative discussion
There were no usertags set.
Usertags are now: normative discussion.
> severity 945275 wishlist
Bug #945275 [debian-policy] debian-policy: [9.1.2] deprecated `staff` group 
special case
Severity set to 'wishlist' from 'normal'
> thanks
Stopping processing here.

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

Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field

[Russ Allbery]

Samuel Thibault  writes:

> I didn't find a previous discussion on this: it would be useful to
> support negated architecture specifications in the debian/control
> Architecture field, so that we can e.g. write:

> Architecture: !s390 !s390x
> (for xorg stuff)

> Architecture: !hppa !hurd-any !kfreebsd-any
> (for java stuff)

> and even things like

> Architecture: linux-any kfreebsd-any !hppa !m68k-any

> which would be understood as [ (linux-any or kfreebsd-any) and not hppa
> and not m68k-any ]. I.e. if no positive specification is set, an "any"
> positive specification is assumed.

> That would help to remove quite a few entries of
> https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific
> and avoid packages with some java bits to have to hardcode the list of
> ports on which java jni bindings packages should be built.

> I guess support would be needed in dpkg, lintian, etc.

Hi Samuel,

I agree that this would be useful.  This has come up frequently over the
years, and back when I was maintaining architecture-specific packages, the
lack of this feature was often annoying.

But (as may be obvious from the long delay in even getting a response),
Policy can't drive the implementation of this change and therefore
probably isn't a good place to start with the request.  I think it would
need to start with dpkg and ftp-master (for DAK).  I'm therefore probably
going to have to close this bug against Policy as unactionable since I
don't know of any efforts towards implementing this support, and Policy
would only be able to change once the support is available.

If I misunderstood the current state, please do let me know.

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

Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area

[Russ Allbery]

Gunnar Wolf  writes:

> It has been four months since the General Resolution 2022/vote_003 was
> voted¹, but it has not yet been completely adopted. The archive area was
> created and at least a package was uploaded to it in October, but it has
> not seen further movement. Two days ago, a call to action for moving
> packages was sent by Cyril Brulebois², and I just sent a mail checking
> for other places where it should be included³.

> ¹ https://www.debian.org/vote/2022/vote_003
> ² https://lists.debian.org/debian-boot/2023/01/msg00150.html
> ³ https://lists.debian.org/debian-project/2023/01/msg00018.html

> To my surprise, the non-free-firmware archive area has not yet been
> discussed for inclusion in the Policy.

> I am (now!) aware there is a clear process to get changes included in
> the Policy, but this is the first time I do this, so please excuse me
> for jumping all the way to "State D: Wording proposed" (of course, my
> words can be checked and improved, particularly given I'm not a native
> English speaker).

> ⁴ https://www.debian.org/doc/debian-policy/ap-process.html

> I am suggesting the following patch, which I'm attaching to this bug
> report, and also uploaded them to my fork of debian-policy in Salsa:

> 
> https://salsa.debian.org/gwolf/policy/-/commit/79c58a40065c01f56850f86e883d8fa482c7cca0

Thank you!  I also second this change, and have merged it for the next
version of Policy, including the fixes suggested by James Addison.  I
numbered the footnotes in chapter two so that both non-free and
non-free-firmware could reference the same footnote.

An editorial note: Gunnar's patch introduced non-free-firmware after main
and before contrib and non-free, and after some consideration I kept that
order because I think it reflects the high likelihood that the typical
user will encounter the non-free-firmware archive area given the results
of the GR.  That does mean that the contrib and non-free sections have
been renumbered to 2.2.3 and 2.2.4, which resurrects a section 2.2.4 that
previously was for non-US back when we had cryptography restrictions.  I
don't think this will cause any actual problems (and one of my long-term
wishlist items is for Policy to rely less on section numbering, which is
inherently unstable, and switch to some sort of persistent ID), but it
seemed worth mentioning.

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