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

[Russ Allbery]

As usual, the things I notice only after I post text, even though I'd
already read it several times.

Russ Allbery  writes:

> +Volatile and temporary files (``tmpfiles.d``)
> +-
> +
> +Some packages require empty directories, files with trivial content (such
> +as short fixed strings), or symlinks in ``/var`` or ``/etc`` to implement
> +their functionality.

Luca carefully worded this to avoid talking about files in /etc, and then
I lost that distinction.  I now have:

Some packages require empty directories in ``/var`` or ``/etc``, or
symlinks or files with trivial content in ``/var``, to implement their
functionality.

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

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

[Russ Allbery]

Luca Boccassi  writes:

> Moved as suggested. Also incorporated your suggestion on the versioned
> virtual package dependency verbatim.

Okay, I felt like doing editing this evening, apparently, so even though
only you, Sam, and Simon had a chance to respond, I went ahead and did the
editing.  I'm guessing we still have some discussion to get through, but
attached is a revised diff that I think captures the content of your diff
but adds some additional explanation and justification that I was kind of
craving.  Please let me know if I messed up any of the meaning here.

Note that this adds a must (held over from Luca's "required") for init
systems.  I don't want to introduce that into Policy until the sysvinit
maintainers have had a chance to weigh in or someone can confirm that
sysvinit already handles running systemd-tmpfiles appropriately when it is
installed.

I should note that I dropped the admonition in the maintainer scripts
section to use upstream's tmpfiles.d files because admonitions of this
type (from Lintian and elsewhere) annoy me.  The maintainer is in the best
possible position to balance the advantages of using upstream
configuration that is shared across distributions, bugs in the upstream
version that aren't fixed, upstream's ability to maintain those files
directly, whether upstream accepts contributions promptly, and whether
there are Debian-specific integration concerns that need to be addressed.

Less personally and more specific to Policy, making appropriate decisions
about when to use upstream files and when to use Debian-specific files is
a maintainer experience and expertise issue, not a Policy issue.  Policy
defines how the packages should work and is agnostic about where the
pieces of it come from.  If we want to give maintainers advice on how to
integrate upstream packages, I think that should go into Developers
Reference instead.

There was some earlier discussion in this bug about the possibility of
using tmpfiles.d to manage things like /run directories that, under
sysvinit, are currently managed in a somewhat ad hoc and untrackable way,
such as via mkdir in the init script.  I still think there's something
there, but I don't see a good way to describe it without creating possible
problems, so I left it out.

> We don't have to handle it with this change/bug and as mentioned I've
> already reworded it as suggested, but to clarify my thinking there, the
> place I was coming from was the factory reset and first boot angle. When
> doing a first boot with only the OS vendor tree under /usr and nothing
> else, you want to get to a working system, and if there are complex
> files created under /var by maintainer scripts, that's kinda of a
> problem.

Should Debian decide to adopt the OS vendor tree concept, I certainly
understand how what gnubg does would interfere with that.  This seemed
like the best of a set of bad options at the time.  I may adopt Simon's
idea of just putting the generated file in /usr, which would also allow me
to drop a Debian-specific patch; I didn't do that because putting files in
/usr that dpkg doesn't know about felt icky, but Simon is correct that
there are a lot of other precedents.

> Perhaps those complex binaries should be created by oneshot services
> that run at boot with a ConditionPathExists=!/var/some/complex/binary
> other than maintainer scripts? That way if /var is blown away, you still
> get a working system on next boot.

Yes, I could also do something like that.  Of course, the point may be
moot if upstream never ports GNU Backgammon to anything newer than Gtk+ 2,
and the chances of that port currently aren't looking great.

> But again, happy to shelve this for now, as it's a more complex topic.

Agreed, we don't have to cross this bridge today.

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

diff --git a/policy/ch-files.rst b/policy/ch-files.rst
index b34c183..cc685fe 100644
--- a/policy/ch-files.rst
+++ b/policy/ch-files.rst
@@ -722,6 +722,65 @@ The name of the files and directories installed by binary packages
 outside the system PATH must be encoded in UTF-8 and should be
 restricted to ASCII when it is possible to do so.
 
+.. _s-tmpfiles.d:
+
+Volatile and temporary files (``tmpfiles.d``)
+-
+
+Some packages require empty directories, files with trivial content (such
+as short fixed strings), or symlinks in ``/var`` or ``/etc`` to implement
+their functionality.  Examples include directories under ``/var/cache``
+that are writable by the package as cache areas, an initially-empty
+directory in ``/etc`` intended for local overrides added by the local
+system administrator, or a file in ``/var`` that should default to a
+symlink elsewhere on the system but may be changed later.
+
+Rather than include these files and directories in the binary package or
+create them in package maintainer scripts, packages should use the
+``tmpfiles.d`` mechanism to specify 

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

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 23:24:24)
> Jonas Smedegaard  writes:
> 
> > I have so far worked the most on identifying and grouping source data,
> > putting only little attention (yet - but do dream big...) towards
> > parsing and processing debian/copyright files e.g. to compare and assess
> > how well aligned the file is with the content it is supposed to cover.
> 
> > So if I understand your question correctly and you are not looking for
> > the output of `licensecheck --list-licenses`, then unfortunately I have
> > nothing exciting to offer.
> 
> I think that's mostly correct.  I was wondering what would happen if one
> ran licensecheck debian/copyright, but unfortunately it doesn't look like
> it does anything useful.  I tried it on one of my packages (remctl) that
> has a bunch of different licenses, and it just said:
> 
> debian/copyright: MIT License
> 
> and apparently ignored all of the other licenses present (FSFAP, FSFFULLR,
> ISC, X11, GPL-2.0-or-later with Autoconf-exception-generic, and
> GPL-3.0-or-later with Autoconf-exception-generic).  It also doesn't notice
> that some of the MIT licenses are variations that contain people's names.
> 
> (I still put all the Autoconf build machinery licenses in my
> debian/copyright file because of the tooling I use to manage my copyright
> file, which I also use upstream.  I probably should change that, but I
> need to either switch to licensecheck or rewrite my horrible script.)
> 
> Also, presumably it doesn't know about copyright-format since it wouldn't
> be expecting that in source files, so it wouldn't know to include licenses
> referenced in License stanzas without the license text included.

Right.  Licensecheck so far mostly scans for human prose stating "this
has been licensed as..." and "this is the license...", and rarely is
able to recognize "the default license of this project is..." or "that
folder over there is licensed as..." style prose.

That said, there is interest in covering that as well, and also interest
in improving on non-prose forms like "[this is YAML;] Copyright: ..." or
binary forms most commonly embedded in fonts and ICC data in images.

It is helpful if you (i.e. anyone reading this) have a good (as in
particularly rich/tricky/peculiar) case that you file a bugreport
pointing to its failure of being recognized by licensecheck.

Also, I hadn't thought of there being interest in statistics - it should
not be too hard to spit out numbers for variation in licenses or
copyright holders once licensecheck has recognized the information.
Again, if someone has suggestions for formats they'd particularly like
such statistisc to be served from licensecheck then please file a
bugreport.

Sorry this isn't helping anything for the topic being discussed.


 - 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, usertagging 970234 ...

[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 970234 = normative
Usertags were: normative.
Usertags are now: normative.
> tags 970234 = pending
Bug #970234 [debian-policy] consider dropping "No hard links in source packages"
Added tag(s) pending; removed tag(s) patch.
> thanks
Stopping processing here.

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

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

[Russ Allbery]

Guillem Jover  writes:

> I'm not really sure what the footnote really refers to, TBH, as I'm not
> aware of any such check, or what would require a fair amount of
> work.

Yeah, it seems to be a mystery to everyone.  There is an explicit entry in
the debian/changelog of Policy from Ian Jackson about it for version
2.1.1, but all it says is:

  * Hard links are forbidden in source packages (they didn't work anyway,
and can't easily be made to work reliably).

This is from when Ian was maintaining dpkg, so presumably he thought
something was broken at the time, but it seems to have been lost in
history.  They do obviously work now.

> Besides the other potential issues mentioned on the bug, which I agree
> we might not care much about, a case that comes to mind would be that
> patching hard linked source files can end up being very confusing, and
> might not really break the build but can end up not producing what one
> might expect. I've quickly prepared the attached tentative and
> completely untested patch, to add a warning in that case, which I guess
> I might be targeting for dpkg 1.22.1 (once I've added some tests).

Thanks, that does seem like a good idea.

> But given that hard links in source packages do not seem prevalent at
> all, and that the tooling or linters can be improved in that direction I
> suppose it might make sense to lift this specific restriction.

Thank you for the review!  Now applied for the next release of Policy.

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

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

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

For a variety of reasons, I support this.


--Sam

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 10:15 PM Russ Allbery  wrote:

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

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 6:33 PM Russ Allbery  wrote:

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

Bug#830913: debian-policy: Allow amd64 systems without /lib64

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 2:15 PM Russ Allbery  wrote:

> Russ Allbery  writes:
>
> > 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.
>
> For the sake of the record on this now-closed bug, I got a reply from
> Javier Serrano Polo asking if I had received a message related to this bug
> last year.  I don't remember receiving one, and it's not present in the
> BTS.  I attempted to reply to that message saying so, but the jasp.net
> mail server rejected my mail message with the following bounce message:
>
> : host
> www.jasp.net[84.126.37.22] said: 550-The message does not meet the
> trust
> level of one recipient at least 550-See
> http://www.jasp.net/smtp/trust.xhtml 550 Administrative prohibition
> (in
> reply to end of DATA command)
>
> I don't think this changes anything about the original analysis, so I'm
> leaving this bug closed, but I wanted to clarify my last message;
> apparently there is some communication blockage here.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 5:48 PM Russ Allbery  wrote:

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

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 10:12 PM Russ Allbery  wrote:

> 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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 6:51 PM Russ Allbery  wrote:

> 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#1030382: marked as done (encourage Vcs-Git over other Vcs-* headers)

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 10:39 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> 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
>
>
>
> -- Forwarded message --
> From: Jelmer Vernooij 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 3 Feb 2023 17:24:36 +
> Subject: encourage Vcs-Git over other Vcs-* headers
> 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  
>
>
>
> -- Forwarded message --
> From: Russ Allbery 
> To: Jelmer Vernooij 
> Cc: 1030382-d...@bugs.debian.org
> Bcc:
> Date: Sat, 09 Sep 2023 19:35:06 -0700
> Subject: Re: Bug#1030382: encourage Vcs-Git over other Vcs-* headers
> 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)  

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 6:18 PM Russ Allbery  wrote:

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

Bug#991984: closed by Russ Allbery (Re: Bug#991984: Please document minimal environment variable needed for sensible-utils)

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 4:21 AM Bastien Roucariès  wrote:

> Le dimanche 10 septembre 2023, 04:33:06 UTC Debian Bug Tracking System a
> écrit :
> > This is an automatic notification regarding your Bug report
> > which was filed against the debian-policy package:
> >
> > #991984: Please document minimal environment variable needed for
> sensible-utils
> >
> > It has been closed by Russ Allbery .
> >
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Russ Allbery <
> r...@debian.org> by
> > replying to this email.
> >
> Seems sensible note that linux manpages mandate now some behavior for
> EDITOR, PAGER and VISUAL
>
> Bastien
>
>

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 1:42 PM Russ Allbery  wrote:

> This patch from a while back is still waiting for one more second before
> it can be merged for the next Policy release.  It previously got one
> second from Wouter.  I revised the patch to mention the experimental suite
> as well as the backports suites.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 5:57 PM Russ Allbery  wrote:

> 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#1020248: debian-policy: Clarifying nomenclature for control file names

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 2:33 PM Russ Allbery  wrote:

> Guillem Jover  writes:
>
> > Seems I missed another file:
>
> >   * .changes:
> > policy → «upload control file» / «Debian changes file»
> > dpkg   → «upload control file» / «.changes control file» /
> >  «Debian .changes file» / «Debian changes file»
>
> [...]
>
> > For changes I think something like the following might be a more clear
> > option (and has the minor bonus of aligning perfectly on the first
> > words! :), with it mentioning explicitly this is about changes being
> > uploaded, and that it is a control file (but I'm not sure I'm entirely
> > convinced about it):
>
> > * .changes:   «Debian upload changes control files»
>
> [...]
>
> > I've also found instances of «record» and «section» referring to fields
> > or stanzas.
>
> [...]
>
> > I also recalled another term that has always seemed very confusing in
> > context: «control information files» or «control information area». For
> > example in a sentence such as “the control file is a control information
> > file in the control information area in a .deb archive”. :) This also
> > seems confusing when some of the files in the .deb control member are
> > not really “control files” with a deb822(5) format.
>
> > My thinking has been going into calling these as the «metadata files»,
> > and being located in either the  «metadata part of the .deb archive» or
> > explicitly the «control member of the .deb archive», in contrast to the
> > filesystem part. In dpkg I'd be eventually switching to meta/metadata
> > and fsys/filesystem, from control or info and data. I've added a patch
> > with the proposed change, but again nothing set in stone, and I'm again
> > open to discussing pros/cons of this.
>
> > Attached the proposals for discussion/review, and I might again have
> > perhaps missed instances or similar.
>
> All of these changes seem straightforward and uncontroversial to me, and
> there are huge advantages to using consistent terminology between Policy
> and dpkg.  I have applied all of them for the next Policy release.  Thank
> you!
>
> --
> Russ Allbery (r...@debian.org)  
>
>

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 1:33 PM Russ Allbery  wrote:

> Here is an updated proposed change for this bug, incorporating Guillem's
> suggestions.  It is ready for seconds.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 10:54 PM Russ Allbery  wrote:

> 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#970234: consider dropping "No hard links in source packages"

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 1:45 PM Russ Allbery  wrote:

> This patch is still waiting for one more second.  It was previously
> seconded by Helmut.
>
> Russ Allbery  writes:
>
> > Here is a patch dropping the restriction on hard links in source
> > packages that I think is ready for seconds.  I'm copying Guillem for his
> > review, in case there's some dpkg concern.
>
> > From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
> > From: Russ Allbery 
> > Date: Thu, 22 Sep 2022 19:15:52 -0700
> > Subject: [PATCH] Allow hard links in source packages
>
> > It's not clear why this restriction was in place, and Debian
> > included a package containing hard links without anyone noticing
> > in the last release.
> > ---
> >  policy/ch-source.rst | 11 ++-
> >  1 file changed, 2 insertions(+), 9 deletions(-)
>
> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index c7415fc..a7df539 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -282,8 +282,8 @@ source files in a package, as far as is reasonably
> possible.  [#]_
> >  Restrictions on objects in source packages
> >  --
> >
> > -The source package must not contain any hard links,  [#]_ device special
> > -files, sockets or setuid or setgid files.. [#]_
> > +The source package must not contain device special files, sockets, or
> > +setuid or setgid files. [#]_
> >
> >  .. _s-debianrules:
> >
> > @@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series``
> for any ``foo``.
> > would be nice if the modification time of the upstream source would
> > be preserved.
> >
> > -.. [#]
> > -   This is not currently detected when building source packages, but
> > -   only when extracting them.
> > -
> > -   Hard links may be permitted at some point in the future, but would
> > -   require a fair amount of work.
> > -
> >  .. [#]
> > Setgid directories are allowed.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

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

[Guillem Jover]

Hi!

On Thu, 2022-09-22 at 19:20:00 -0700, Russ Allbery wrote:
> Russ Allbery  writes:
> > 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.
> 
> Here is a patch dropping the restriction on hard links in source packages
> that I think is ready for seconds.  I'm copying Guillem for his review, in
> case there's some dpkg concern.

I'm not really sure what the footnote really refers to, TBH, as I'm
not aware of any such check, or what would require a fair amount of
work. Besides the other potential issues mentioned on the bug, which
I agree we might not care much about, a case that comes to mind would
be that patching hard linked source files can end up being very
confusing, and might not really break the build but can end up not
producing what one might expect. I've quickly prepared the attached
tentative and completely untested patch, to add a warning in that case,
which I guess I might be targeting for dpkg 1.22.1 (once I've added
some tests).

But given that hard links in source packages do not seem prevalent
at all, and that the tooling or linters can be improved in that
direction I suppose it might make sense to lift this specific
restriction.

> >From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
> From: Russ Allbery 
> Date: Thu, 22 Sep 2022 19:15:52 -0700
> Subject: [PATCH] Allow hard links in source packages
> 
> It's not clear why this restriction was in place, and Debian
> included a package containing hard links without anyone noticing
> in the last release.
> ---
>  policy/ch-source.rst | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index c7415fc..a7df539 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -282,8 +282,8 @@ source files in a package, as far as is reasonably 
> possible.  [#]_
>  Restrictions on objects in source packages
>  --
>  
> -The source package must not contain any hard links,  [#]_ device special
> -files, sockets or setuid or setgid files.. [#]_
> +The source package must not contain device special files, sockets, or
> +setuid or setgid files. [#]_
>  
>  .. _s-debianrules:
>  
> @@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series`` for 
> any ``foo``.
> would be nice if the modification time of the upstream source would
> be preserved.
>  
> -.. [#]
> -   This is not currently detected when building source packages, but
> -   only when extracting them.
> -
> -   Hard links may be permitted at some point in the future, but would
> -   require a fair amount of work.
> -
>  .. [#]
> Setgid directories are allowed.

Seconded.

Thanks,
Guillem
diff --git i/scripts/Dpkg/Source/Patch.pm w/scripts/Dpkg/Source/Patch.pm
index 0da35b9e5..99020885b 100644
--- i/scripts/Dpkg/Source/Patch.pm
+++ w/scripts/Dpkg/Source/Patch.pm
@@ -513,6 +513,11 @@ sub analyze {
 	error(g_("diff '%s' patches something which is not a plain file"),
 	  $diff);
 	}
+my $nlink = (stat _)[3];
+if ($nlink > 1) {
+warning(g_("diff '%s' patches hard link %s which can have " .
+   "unintended consequences"), $diff, $fn);
+}
 
 	if ($filepatched{$fn}) {
 $filepatched{$fn}++;


signature.asc
Description: PGP signature

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

[Guillem Jover]

Hi!

On Sun, 2023-09-10 at 16:31:30 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> > Hmm, the "For this case" comes just after the "no binary packages" which
> > to me reads as being somewhat referring to it, perhaps the "no binary
> > packages" sentence should be put at the end of the paragraph to avoid
> > confusion, or the "For this case" moved instead after the "It is a
> > multiline field" one or something along those lines?
> 
> I knew I should have listened to my instincts and reworded that paragraph
> some more to make it explicit that the format of the field in the .changes
> file is different.  (Unfortunate, but oh well, too late now.)

No worries, that's what reviews are for! :D

> Here is an updated patch that restructures this paragraph to try to make
> this clearer.

Thanks, this is indeed clearer.

> >From 516d0a327e247c35bd1bb95ff2a9bfc773f87c21 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 | 23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 4bab7df..d5c9d68 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 ` (mandatory in some cases)
>  
>  -  :ref:`Architecture ` (mandatory)
>  
> @@ -292,7 +292,7 @@ The fields in this file are:
>  
>  -  :ref:`Changed-By `
>  
> --  :ref:`Description ` (mandatory)
> +-  :ref:`Description ` (mandatory in some cases)
>  
>  -  :ref:`Closes `
>  
> @@ -812,12 +812,16 @@ 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. If no binary
> +packages are being uploaded, this field will not be present.
> +
> +When used inside a ``.changes`` file, the ``Description`` field has a
> +different format than in source or binary control files. It is a multiline
> +field with one line per binary package. The first line of the field value
> +(the part on the same line as ``Description:``) is always empty. Each
> +subsequent 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:
>  
> @@ -927,7 +931,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 no
> +binary packages are being uploaded, this field will not be present.
>  
>  .. _s-f-Installed-Size:
>  

Seconded.

Thanks,
Guillem


signature.asc
Description: PGP signature

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

[Russ Allbery]

Guillem Jover  writes:

> Hmm, the "For this case" comes just after the "no binary packages" which
> to me reads as being somewhat referring to it, perhaps the "no binary
> packages" sentence should be put at the end of the paragraph to avoid
> confusion, or the "For this case" moved instead after the "It is a
> multiline field" one or something along those lines?

I knew I should have listened to my instincts and reworded that paragraph
some more to make it explicit that the format of the field in the .changes
file is different.  (Unfortunate, but oh well, too late now.)

Here is an updated patch that restructures this paragraph to try to make
this clearer.

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

>From 516d0a327e247c35bd1bb95ff2a9bfc773f87c21 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 | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 4bab7df..d5c9d68 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 ` (mandatory in some cases)
 
 -  :ref:`Architecture ` (mandatory)
 
@@ -292,7 +292,7 @@ The fields in this file are:
 
 -  :ref:`Changed-By `
 
--  :ref:`Description ` (mandatory)
+-  :ref:`Description ` (mandatory in some cases)
 
 -  :ref:`Closes `
 
@@ -812,12 +812,16 @@ 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. If no binary
+packages are being uploaded, this field will not be present.
+
+When used inside a ``.changes`` file, the ``Description`` field has a
+different format than in source or binary control files. It is a multiline
+field with one line per binary package. The first line of the field value
+(the part on the same line as ``Description:``) is always empty. Each
+subsequent 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:
 
@@ -927,7 +931,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 no
+binary packages are being uploaded, this field will not be present.
 
 .. _s-f-Installed-Size:
 
-- 
2.40.1

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Sun, 10 Sept 2023 at 03:19, Russ Allbery  wrote:
>> 
>> 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".

Luca> Thank you, looks good to me, seconded.

LGTM too, seconded.



signature.asc
Description: PGP signature

Bug#877697: marked as done (debian-policy: discourage using all 4 digits numbers in Standards-Version)

[Debian Bug Tracking System]

Your message dated Sun, 10 Sep 2023 16:26:20 -0700
with message-id <87y1hdtxsz@hope.eyrie.org>
and subject line Re: Bug#877697: debian-policy: discourage using all 4 digits 
numbers in Standards-Version
has caused the Debian Bug report #877697,
regarding debian-policy: discourage using all 4 digits numbers in 
Standards-Version
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.)


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

Policy § 5.6.11, after describing the meaning of the digits in the
policy version, reads:

| 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. [5]


Now, I've only got the impressions that packages should avoid using the
4th digit in their Standards-Version field, as that number has no
meaning when it comes to normative stuff.  I've seen on IRC/MLs all kind
of comments saying that the 4th digit should be avoided, and most
packages avoid it indeed, but this wording in the policy makes me feel
like it's pretty much the same.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Mattia Rizzolo  writes:

> Policy § 5.6.11, after describing the meaning of the digits in the
> policy version, reads:

> | 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. [5]

> Now, I've only got the impressions that packages should avoid using the
> 4th digit in their Standards-Version field, as that number has no
> meaning when it comes to normative stuff.  I've seen on IRC/MLs all kind
> of comments saying that the 4th digit should be avoided, and most
> packages avoid it indeed, but this wording in the policy makes me feel
> like it's pretty much the same.

After some discussion of this six years ago, it doesn't look like there
was any consensus to change Policy here.  Most people only use three
numbers.  Some people prefer to use four numbers to make it very clear
what version of Policy they looked at, and just in case informative
updates were relevant (probably a bug in Policy if that happens, but maybe
not).

I think it's therefore fine to use either, which is what Policy says now,
so I'm going to close this bug.

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

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

[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 877697 = normative
Usertags were: normative discussion.
Usertags are now: normative.
> tags 877697 = wontfix
Bug #877697 [debian-policy] debian-policy: discourage using all 4 digits 
numbers in Standards-Version
Added tag(s) wontfix.
> thanks
Stopping processing here.

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

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

[Guillem Jover]

Hi!

On Sun, 2023-09-10 at 10:30:41 -0700, Russ Allbery wrote:
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 4bab7df..904fa52 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -812,10 +812,11 @@ 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
> +the descriptions of the binary packages being uploaded. If no binary
> +packages are being uploaded, this field will not be present. For this
> +case, the first line of the field value (the part on the same line as
> +``Description:``) is always empty.

Hmm, the "For this case" comes just after the "no binary packages"
which to me reads as being somewhat referring to it, perhaps the "no
binary packages" sentence should be put at the end of the paragraph to
avoid confusion, or the "For this case" moved instead after the "It is
a multiline field" one or something along those lines?

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

Thanks,
Guillem

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Sun, 10 Sept 2023 at 11:31, Simon McVittie  wrote:
>> 
>> On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
>> > 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
>> 
>> I'm not Luca, but I think you're correct here.

Luca> Moved as suggested. Also incorporated your suggestion on the
Luca> versioned virtual package dependency verbatim.

>> > Luca Boccassi  writes: > > +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.
>> 
>> In general tmpfiles.d handles files that exist only as metadata:
>> symbolic links (for which the target is the only interesting
>> fact), empty files (for which the existence and
>> ownership/permissions are the only interesting facts),
>> directories (ditto) and so on.
>> 
>> It can also handle files that have static initial contents that
>> do not vary between systems, but can change in a system-specific
>> way later, with initial contents either hard-coded in the
>> tmpfiles.d snippet (for short text strings) or copied from
>> somewhere below /usr (canonically /usr/share/factory).
>> 
>> Files generated by non-trivial imperative code, like
>> machine-specific initial contents (/var/lib/dbus/machine-id) or
>> some sort of compiler (/var/lib/gnubg/gnubg_ts0.bd, as far as I
>> can tell), are out of scope for tmpfiles.d, so I think you're
>> right to be concerned that Luca's wording as written is asking
>> gnubg to do something that is unimplementable.
>> ch-maintainerscripts.rst has the same issue.
>> 
>> Perhaps "files with trivial contents that are located under /var"
>> would be a good wording that is not overly specific about
>> implementation details, covers the 90% case, and leaves room for
>> exceptions by declaring packages like dbus and gnubg to be
>> non-trivial?

Luca> I have reworded as suggested, citing symlinks or short fixed
Luca> strings as examples.

I second this patch, and do not need to additionally review Russ's
minor rewordings

--Sam


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Here is an updated proposed change for this bug, incorporating
Russ> Guillem's suggestions.  It is ready for seconds.

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

I have reviewed the patch; I support the idea and second the specific
wording.


signature.asc
Description: PGP signature

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

[Russ Allbery]

Jonas Smedegaard  writes:

> I have so far worked the most on identifying and grouping source data,
> putting only little attention (yet - but do dream big...) towards
> parsing and processing debian/copyright files e.g. to compare and assess
> how well aligned the file is with the content it is supposed to cover.

> So if I understand your question correctly and you are not looking for
> the output of `licensecheck --list-licenses`, then unfortunately I have
> nothing exciting to offer.

I think that's mostly correct.  I was wondering what would happen if one
ran licensecheck debian/copyright, but unfortunately it doesn't look like
it does anything useful.  I tried it on one of my packages (remctl) that
has a bunch of different licenses, and it just said:

debian/copyright: MIT License

and apparently ignored all of the other licenses present (FSFAP, FSFFULLR,
ISC, X11, GPL-2.0-or-later with Autoconf-exception-generic, and
GPL-3.0-or-later with Autoconf-exception-generic).  It also doesn't notice
that some of the MIT licenses are variations that contain people's names.

(I still put all the Autoconf build machinery licenses in my
debian/copyright file because of the tooling I use to manage my copyright
file, which I also use upstream.  I probably should change that, but I
need to either switch to licensecheck or rewrite my horrible script.)

Also, presumably it doesn't know about copyright-format since it wouldn't
be expecting that in source files, so it wouldn't know to include licenses
referenced in License stanzas without the license text included.

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

Bug#917995: marked as done (debian-policy: drop section 1.6 Translations)

[Debian Bug Tracking System]

Your message dated Sun, 10 Sep 2023 14:11:41 -0700
with message-id <87fs3lvilu@hope.eyrie.org>
and subject line Re: Bug#917995: debian-policy: drop section 1.6 Translations
has caused the Debian Bug report #917995,
regarding debian-policy: drop section 1.6 Translations
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.)


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

Hi,

I hereby propose to drop section 1.6 Translations and the following
sentence: "When translations of this document into languages other
than English disagree with the English text, the English text takes
precedence."

If it is wrongly translated, then the English text probably isn't
clear enough (otherwise the translation would have the same meaning)
and would need to be clarified anyway to avoid being ambigious.  Even
if not, the same process can be used to clarify the meaning of
non-English versions.

There should be no need to put one language over others.

Ansgar
--- End Message ---
--- Begin Message ---
Ian Jackson  writes:
> Sean Whitton writes:

>> I'm still inclined to prioritise unblocking people, by giving them a
>> way of resolving disputes between versions of the document without
>> asking on d-policy, but let's see.

> It is the English text of policy that is reviewed and discussed and
> approved here.  That is, the "untranslated" policy.  It is quite wrong
> to say that the English text is not special.  If it is desired to
> provide normative text in other language(s), that text should be
> discussed and approved in the same way as the English text.

> Even so, that leaves open the possibility for multiple normative texts
> which disagree.  (This has occurred frequently in international treaties
> with multiple normative texts and is a source of trouble.)

I agree with Ian's argument here.

Policy doesn't have a lot of resources for writing text, let alone
translating text, so realistically our translations are unlikely to be
comprehensive and will probably be the work of one or two people.  I think
they may be very useful because Policy is a complicated text and reading
complicated descriptions in one's non-native language is difficult, but in
practice I expect the most common use of the translations will be in
conjuction with the English text.

The English text is where nearly all of the work and review goes at
present, so it is special in that sense.  The delegated Policy Editors
only maintain the English text.  It's common in that situation to point
that out in the document.

I hear Jonathan's point that treating Policy as a standards document is
perhaps a triumph of hope over experience, but in practice it is used to
settle disagreements in Debian, however imperfectly, and in those cases
the English text is the one that's been peer-reviewed and is more likely
to resolve the disagreement.

Given all of this, and the general lack of consensus in this bug for
making a change, I'm going to close this bug.

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

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

[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 917995 = normative
Usertags were: discussion normative.
Usertags are now: normative.
> tags 917995 = wontfix
Bug #917995 [debian-policy] debian-policy: drop section 1.6 Translations
Added tag(s) wontfix.
> thanks
Stopping processing here.

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

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

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 21:41:59)
> Jeremy Stanley  writes:
> 
> > I'm surprised, for example, by the absence of the ISC license given that
> > not only ISC's software but much of that originating from the OpenBSD
> > ecosystem uses it. My personal software projects also use the ISC
> > license. Are you aggregating the "License:" field in copyright files
> > too, or is it really simply a hard-coded list of matching patterns?
> 
> It's only a hard-coded list of matching patterns, and it doesn't match any
> of the short licenses because historically I wasn't considering them (with
> the exception of common-licenses references to the BSD license, which I
> kind of would like to make an RC bug and clean up so that we could remove
> the BSD license from common-licenses on the grounds that it's specific to
> only the University of California and confuses people).  If we go with any
> sort of threshold, the script will need serious improvements.
> 
> That was something else I wanted to ask: I've invested all of a couple of
> hours in this script, and would be happy to throw it away in favor of
> something that tries to do a more proper job of classifying the licenses
> referenced in debian/copyright.  Has someone already done this (Jonas,
> perhaps)?

I have so far worked the most on identifying and grouping source data,
putting only little attention (yet - but do dream big...) towards
parsing and processing debian/copyright files e.g. to compare and assess
how well aligned the file is with the content it is supposed to cover.

So if I understand your question correctly and you are not looking for
the output of `licensecheck --list-licenses`, then unfortunately I have
nothing exciting to offer.


 - 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

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

[Timo Röhling]

* Russ Allbery  [2023-09-10 09:16]:

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.


In the thread so far, there's been a bit of early convergence around my
threshold of 100 packages above.  I want to make sure people realize that
this is a very conservative threshold that would mean saying no to most
new license inclusion requests.

My guess is that with the threshold set at 100, we will probably add
around eight new licenses with the 25 line threshold (AGPL-2,
Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
OFL-1.1, and I'm not sure about some of those because the CC licenses have
variants that would each have to reach the threshold independently; my
current ad hoc script does not distinguish between the variants), and
maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
the BSD licenses).  This would essentially be continuing current practice
except with more transparent and consistent criteria.  It would mean not
including a lot of long legal license texts that people have complained
about having to duplicate, such as the CDDL, CeCILL licenses, probably the
EPL, the Unicode license, etc.

If that's what people want, that's what we'll do; as I said, that's what I
would do if the choice were left entirely up to me.  But I want to make
sure I give the folks who want a much more relaxed standard a chance to
speak up.


For me, this outcome would already be an improvement over the current
situation and alleviate my biggest pain point (CC licenses).
Still, I'd like to be significantly more relaxed.

I propose the following three criteria must be satisfied for
inclusion in /usr/share/common-licenses:

 * The license is DFSG-free.
 * Exactly the same license wording is used by all works covered by it.
 * The license is in the SPDX list of common licenses 
(https://spdx.org/licenses/)
   OR
   The license applies to at least 100 source packages in Debian.


I am not committed to the 100 source packages threshold, it is
mostly intended as fallback for a hypothetical future license which
is super popular but for some reason does not make it to the SPDX
list in a timely manner.

One very intentional side effect of my proposal is a nudge towards
using SPDX License Identifiers in d/copyright files.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

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

[Russ Allbery]

Johannes Schauer Marin Rodrigues  writes:

> I very much like this idea. The main reason maintainers want more
> licenses in /usr/share/common-licenses/ is so that they do not anymore
> have humongous d/copyright files with all license texts copypasted over
> and over again. If long texts could be reduced to a reference that get
> expanded by a machine it would make debian/copyright look much nicer and
> would make it easier to maintain while at the same time shipping the
> full license text in the binary package.

> Does anybody know why such an approach would be a bad idea?

I can think of a few possible problems:

* I'm not sure if we generate binary package copyright files at build time
  right now, and if all of our tooling deals with this.  I had thought
  that we prohibited this, but it looks like it's only a Policy should and
  there isn't a mention of it in the reject FAQ, so I think I was
  remembering the rule for debian/control instead.  Of course, even if
  tools don't support this now, they could always be changed.

* If ftp-master has to review the copyright files of each binary package
  separate from the copyright file of the source package (I think this
  would be an implication of generating the copyright files during build
  time), and the binary copyright files have fully-expanded licenses, that
  sounds like kind of a pain for the ftp-master reviewers.  Maybe we can
  deal with this with better tooling, but someone would need to write
  that.

* If we took this to its logical end point and did this with the GPL as
  well, we would add 20,000 copies of the GPL to the archive and install a
  *lot* of copies on the system.  Admittedly text files are small and
  disks are large, but this still seems a little excessive.  So maybe we
  still need to do something with common-licenses?

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

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

[G. Branden Robinson]

At 2023-09-10T21:47:36+0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Bill Allombert (2023-09-10 18:29:36)
> > On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> > > Jonas Smedegaard  writes:
> > > >>  Hmm, how about providing license-common package and that
> > > >>  depends on "license-common-list", and ISO image provides both,
> > > >>  then? It would be no regressions.
> > > 
> > > I do wonder why we've never done this.  Does anyone know?
> > > common-licenses is in an essential package so it doesn't require a
> > > dependency and is always present, and we've leaned on that in the
> > > past in justifying not including those licenses in the binary
> > > packages themselves, but I'm not sure why a package dependency
> > > wouldn't be legally equivalent.  We allow symlinking the
> > > /usr/share/doc directory in some cases where there is a
> > > dependency, so we don't strictly require every binary package have
> > > a copyright file.
> > 
> > Or we could generate DEBIAN/copyright from debian/copyright using data in
> > license-common-list at build time. So maintainers would not need to manage
> > the copying themselves.
[...]
> I have zero legal training so the only potential problem with this approach
> that I was able to come up with is, that then the source package itself would
> not anymore contain the license text

...why wouldn't it?  Remember how a source package is defined:

A DSC file, an upstream source archive (maybe more than one in exciting
new source formats I haven't learned), and a compressed diff of Debian
changes.

Debian _source_ packages generally don't chop copyright notices and
license texts out the upstream distributions, and should not do so
unless those notices/texts are invalid or the material they cover has
been removed.  (Both of these do sometimes happen.)

Even if one worries about theoretical liability due to the existence of
separate files for .dsc, .tar.gz, and .diff.gz, then let us recall that
(1) the DSC is minimal, containing metadata that may not rise to the
threshold or originality required by copyright [in the U.S., anyway];
(2) the upstream archive has the notices and texts that the _original
distributor_ put in it, and as a rule, if permission to distribute the
work exists, it is not incumbent on redistributors to add notices/texts
where the rightsholder themselves neglected to do so; and (3) the
.diff.gz will not be in the business of removing notices/texts except as
contemplated in the previous paragraph (correcting erroneous
notices).[1]

> and thus we would be shipping code covered by a license that states
> that the code may only be distributed with the license text alongside
> it without that text.

I don't think that is a risk as long as people continue to follow
packaging practices that Debian has applied with little objection from
our upstreams for 25+ years.[2]

> So while auto-generating this would probably create compliant binary
> packages, it would leave the source package without the license text.

I am unable to imagine the mechanism by which that would happen, given
what Russ and Bill proposed.

Regards,
Branden

[1] When repackaging, e.g., to remove non-free material, affected
content is removed altogether even from the source.  Nothing in
copyright law can compel you to distribute copyright notices and
texts that don't apply to work you're not distributing.[3]

[2] I don't know of Debian _ever_ having had a problem, as in receiving
a cease-and-desist letter or other threat of legal action with what
one might term an "institutional" copyright holder.  We've certainly
had our share of nasty emails from cantankerous individual copyright
holders, often who had their own perverse misreadings of licenses
drafted by others (hello to the memory of Jörg Schilling).  There
also was once an upstream who stuck a Trojan horse into the source
code to try to get Debian's users to stop using versions we
distributed, but to go directly upstream instead.  Nowadays, that
seems quaint; you can today Trojan your machine much more
conveniently with npm(1).

[3] At the same time a few non-free FSF manuals under the GNU FDL
declaim the GNU _GPL_ text to be an Invariant Section.  Like most of
the defects of the FDL, I think this is a pointless encumbrance; if
you distribute GPL'ed software, a copy of its text must come along
anyway.  The only rationale I can imagine is to mandate, for printed
copies of the manuals, the inclusion of the GPL's preachy preamble.
But I digress.


signature.asc
Description: PGP signature

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

[Jeremy Stanley]

On 2023-09-09 20:35:27 -0700 (-0700), Russ Allbery wrote:
[...]
> Finally, as promised, here is the count of source packages in
> unstable that use the set of licenses that I taught my script to
> look for.  This is likely not accurate; the script uses a bunch of
> heuristics and guesswork.
[...]

I'm surprised, for example, by the absence of the ISC license given
that not only ISC's software but much of that originating from the
OpenBSD ecosystem uses it. My personal software projects also use
the ISC license. Are you aggregating the "License:" field in
copyright files too, or is it really simply a hard-coded list of
matching patterns?

Regardless, this is great work, thanks for kicking off the
reevaluation!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Bill Allombert (2023-09-10 18:29:36)
> On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> > Jonas Smedegaard  writes:
> > > Quoting Hideki Yamane (2023-09-10 11:00:07)
> > >>  Hmm, how about providing license-common package and that depends on
> > >>  "license-common-list", and ISO image provides both, then? It would be
> > >>  no regressions.
> > 
> > I do wonder why we've never done this.  Does anyone know?  common-licenses
> > is in an essential package so it doesn't require a dependency and is
> > always present, and we've leaned on that in the past in justifying not
> > including those licenses in the binary packages themselves, but I'm not
> > sure why a package dependency wouldn't be legally equivalent.  We allow
> > symlinking the /usr/share/doc directory in some cases where there is a
> > dependency, so we don't strictly require every binary package have a
> > copyright file.
> 
> Or we could generate DEBIAN/copyright from debian/copyright using data in
> license-common-list at build time. So maintainers would not need to manage
> the copying themselves.

I very much like this idea. The main reason maintainers want more licenses in
/usr/share/common-licenses/ is so that they do not anymore have humongous
d/copyright files with all license texts copypasted over and over again. If
long texts could be reduced to a reference that get expanded by a machine it
would make debian/copyright look much nicer and would make it easier to
maintain while at the same time shipping the full license text in the binary
package.

Does anybody know why such an approach would be a bad idea?

I have zero legal training so the only potential problem with this approach
that I was able to come up with is, that then the source package itself would
not anymore contain the license text and thus we would be shipping code covered
by a license that states that the code may only be distributed with the license
text alongside it without that text. So while auto-generating this would
probably create compliant binary packages, it would leave the source package
without the license text. Is that a problem?

Thanks!

cheers, josch

signature.asc
Description: signature

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

[Russ Allbery]

Jeremy Stanley  writes:

> I'm surprised, for example, by the absence of the ISC license given that
> not only ISC's software but much of that originating from the OpenBSD
> ecosystem uses it. My personal software projects also use the ISC
> license. Are you aggregating the "License:" field in copyright files
> too, or is it really simply a hard-coded list of matching patterns?

It's only a hard-coded list of matching patterns, and it doesn't match any
of the short licenses because historically I wasn't considering them (with
the exception of common-licenses references to the BSD license, which I
kind of would like to make an RC bug and clean up so that we could remove
the BSD license from common-licenses on the grounds that it's specific to
only the University of California and confuses people).  If we go with any
sort of threshold, the script will need serious improvements.

That was something else I wanted to ask: I've invested all of a couple of
hours in this script, and would be happy to throw it away in favor of
something that tries to do a more proper job of classifying the licenses
referenced in debian/copyright.  Has someone already done this (Jonas,
perhaps)?

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

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

[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 590511 = normative
Usertags were: normative discussion.
Usertags are now: normative.
> tags 590511 = patch
Bug #590511 [debian-policy] Document significance of first-listed alternative 
in dependencies
Added tag(s) patch.
> thanks
Stopping processing here.

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

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

[Russ Allbery]

Guillem Jover  writes:

> Seems I missed another file:

>   * .changes:
> policy → «upload control file» / «Debian changes file»
> dpkg   → «upload control file» / «.changes control file» /
>  «Debian .changes file» / «Debian changes file»

[...]

> For changes I think something like the following might be a more clear
> option (and has the minor bonus of aligning perfectly on the first
> words! :), with it mentioning explicitly this is about changes being
> uploaded, and that it is a control file (but I'm not sure I'm entirely
> convinced about it):

> * .changes:   «Debian upload changes control files»

[...]

> I've also found instances of «record» and «section» referring to fields
> or stanzas.

[...]

> I also recalled another term that has always seemed very confusing in
> context: «control information files» or «control information area». For
> example in a sentence such as “the control file is a control information
> file in the control information area in a .deb archive”. :) This also
> seems confusing when some of the files in the .deb control member are
> not really “control files” with a deb822(5) format.

> My thinking has been going into calling these as the «metadata files»,
> and being located in either the  «metadata part of the .deb archive» or
> explicitly the «control member of the .deb archive», in contrast to the
> filesystem part. In dpkg I'd be eventually switching to meta/metadata
> and fsys/filesystem, from control or info and data. I've added a patch
> with the proposed change, but again nothing set in stone, and I'm again
> open to discussing pros/cons of this.

> Attached the proposals for discussion/review, and I might again have
> perhaps missed instances or similar.

All of these changes seem straightforward and uncontroversial to me, and
there are huge advantages to using consistent terminology between Policy
and dpkg.  I have applied all of them for the next Policy release.  Thank
you!

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

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

[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 1020248 = informative
Usertags were: informative.
Usertags are now: informative.
> tags 1020248 = pending
Bug #1020248 [debian-policy] debian-policy: Clarifying nomenclature for control 
file names
Added tag(s) pending; removed tag(s) patch.
> usertags 984511 = normative
Usertags were: normative.
Usertags are now: normative.
> tags 984511 = pending
Bug #984511 [debian-policy] debian-policy: please clarify how archive areas can 
be combined in source packages
Bug #994008 [debian-policy] debian-policy: Clarify relationship between source 
and binary packages' archive areas
Added tag(s) pending; removed tag(s) patch.
Added tag(s) pending; removed tag(s) patch.
> thanks
Stopping processing here.

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

Bug#830913: debian-policy: Allow amd64 systems without /lib64

[Russ Allbery]

Russ Allbery  writes:

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

For the sake of the record on this now-closed bug, I got a reply from
Javier Serrano Polo asking if I had received a message related to this bug
last year.  I don't remember receiving one, and it's not present in the
BTS.  I attempted to reply to that message saying so, but the jasp.net
mail server rejected my mail message with the following bounce message:

: host
www.jasp.net[84.126.37.22] said: 550-The message does not meet the trust
level of one recipient at least 550-See
http://www.jasp.net/smtp/trust.xhtml 550 Administrative prohibition (in
reply to end of DATA command)

I don't think this changes anything about the original analysis, so I'm
leaving this bug closed, but I wanted to clarify my last message;
apparently there is some communication blockage here.

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

Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas

[Russ Allbery]

Simon McVittie  writes:

> Here are some updated patches for Policy, incorporating this requirement.

> I have not attempted to incorporate the corner case involving
> build-profiles. I think if we were going to do that, it would require
> documenting build-profiles first (#757760), and maybe even then it's too
> much of a corner-case to be documenting unless/until it actually
> happens.

I also second these changes.  In the name of expediency, and since I
believe all the proposed wording changes were informative, I applied these
patches for the next release and made the wording changes suggested by
Holger and Sean.  Attached are the changes as committed.

Subsequent to this work, we added the non-free-firmware archive area.
Simon's patch therefore doesn't add a statement to that section about
whether source packages in non-free-firmware are allowed to produce
binaries in non-free, or if source packages in non-free are allowed to
produce binaries in non-free-firmware, and I don't know what the answer to
that is.

Would the following wording be correct?

If a source package is in the *non-free-firmware* archive area, then
each of the binary packages that it produces must also be in the
*non-free-firmware* archive area.

Please let me know, and I will propose some follow-up wording for that.

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

diff --git a/debian/changelog b/debian/changelog
index 66d6fa0..a5e3e3e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,11 @@ debian-policy (4.6.3.0) UNRELEASED; urgency=medium
 Seconded: Russ Allbery 
 Seconded: Holger Levsen 
 Closes: #1035733
+  * Policy: Source packages in main may build binary packages in contrib
+Wording: Simon McVittie 
+Seconded: Holger Levsen 
+Seconded: Russ Allbery 
+Closes: #994008
 
  -- Sean Whitton   Wed, 14 Jun 2023 16:58:40 +0100
 
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index c7cd340..eb8978a 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -136,6 +136,27 @@ In addition, the packages in *main*
 
 - must meet all policy requirements presented in this manual.
 
+If a source package is in the *main* archive area, then at least one of
+its binary packages must be in the *main* archive area, and each of the
+remaining packages must be in either the *main* or *contrib* archive
+area. Each binary package's archive area is indicated by its ``Section``
+field: see :ref:`s-subsections`.
+
+Source packages in *main* with a mixture of *main* and *contrib* binary
+packages are more complex for archive tooling to handle, and therefore
+should be limited to situations where it would be inconvenient to split
+the source package. If it is straightforward to split the source package
+into a *main* part and a *contrib* part that are built separately, then
+those parts should be represented as separate source packages.
+
+When a *main* source package has a mixture of *main* and *contrib* binary
+packages, the source package and the *main* binary packages must follow
+the requirements for *main* packages, but the *contrib* binary packages
+may follow the weaker requirements for *contrib* packages. In particular,
+source packages in *main* must not have build dependencies outside *main*,
+but the *contrib* binary packages may have runtime dependencies outside
+*main*.
+
 .. [2]
See `What Does Free Mean? `_ for
more about what we mean by free software.
@@ -192,6 +213,10 @@ Examples of packages which would be included in *contrib* are:
 - wrapper packages or other sorts of free accessories for non-free
   programs.
 
+If a source package is in the *contrib* archive area, then each of the
+binary packages that it produces must also be in the *contrib* archive
+area.
+
 .. _s-non-free:
 
 The non-free archive area
@@ -214,6 +239,10 @@ In addition, the packages in *non-free*
 - must meet all policy requirements presented in this manual that it is
   possible for them to meet.  [4]_
 
+If a source package is in the *non-free* archive area, then each of the
+binary packages that it produces must also be in the *non-free* archive
+area.
+
 .. [4]
It is possible that there are policy requirements which the package
is unable to meet, for example, if the source is unavailable. These
diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
index 54a473b..6009819 100644
--- a/policy/upgrading-checklist.rst
+++ b/policy/upgrading-checklist.rst
@@ -44,6 +44,13 @@ Version 4.7.0
 
 Unreleased.
 
+2.2.1
+Document that source packages in the *main* archive area may build
+binary packages in the *contrib* archive area, although this is
+discouraged unless the source package is inconvenient to split.  This
+does not relax the requirement that source packages in *main* must not
+have build dependencies outside of *main*.
+
 2.2.2
 The ``non-free-firmware`` archive

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

[Russ Allbery]

Russ Allbery  writes:

> This patch from a while back is still waiting for one more second before
> it can be merged for the next Policy release.  It previously got one
> second from Wouter.  I revised the patch to mention the experimental
> suite as well as the backports suites.

Argh, wrong patch, sorry.  Here is the one that was actually updated to
include experimental.

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

>From 7ee49f6c892d6057b9a0d2f9eb84ff0f35d1d436 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 | 61 +++--
 1 file changed, 45 insertions(+), 16 deletions(-)

diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 5074428..ffafbf1 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 interpreted
+specially by Debian autobuilders. 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,47 @@ 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 discard the dependencies after the first. This is
+done to give alternative dependencies a consistent interpretation that
+reduces the risk of inconsistencies between repeated builds. If, for
+example, the first-listed dependency would normally be available but is
+temporarily not installable, the autobuilder fails rather than install a
+subsequent dependency that may significantly change the behavior of the
+package.
+
+More specifically, Debian autobuilders perform the following
+transformation on alternative dependencies in the ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields:
+
+#. Discard any alternatives that are restricted to architectures that do
+   not match the host architecture.
+#. Discard any alternatives specifying different package names than the
+   now-first alternative. (Alternatives specifying the same package name
+   are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.)
+
+For example, an autobuilder for the ``amd64`` architecture would treat the
+following dependency::
+
+foo-special [armhf] | foo (<= 4) | foo (>= 4.2) | bar
+
+as if it were::
+
+foo (<= 4) | foo (>= 4.2)
+
+The normal effect is to use only the first alternative that is valid on
+the relevant architecture and fail if that alternative is not installable.
+
+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.
+
+The autobuilders for the Debian backports and experimental suites do not
+perform this transformation and instead use the same dependency resolution
+rules as normal package installations to choose which alternative
+dependency to install.
+
 .. _s-built-using:
 
 Additional source packages used to build the binary - ``Built-Using``
@@ -666,21 +710,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``, ``Build-Depends-Indep`` and
-   ``Build-Depends-Arch`` permit the use of alternative dependencies,
-   those are only used for the backports suite on the Debian autobuilders.
-   On the other suites, after reducing any architecture-specific restrictions
-   for the build architecture in question, all but the first alternative are
-   discarded except if the alternative is the same package name as the first.
-   The latter exception is useful to spe

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

[Russ Allbery]

This patch is still waiting for one more second.  It was previously
seconded by Helmut.

Russ Allbery  writes:

> Here is a patch dropping the restriction on hard links in source
> packages that I think is ready for seconds.  I'm copying Guillem for his
> review, in case there's some dpkg concern.

> From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
> From: Russ Allbery 
> Date: Thu, 22 Sep 2022 19:15:52 -0700
> Subject: [PATCH] Allow hard links in source packages

> It's not clear why this restriction was in place, and Debian
> included a package containing hard links without anyone noticing
> in the last release.
> ---
>  policy/ch-source.rst | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)

> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index c7415fc..a7df539 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -282,8 +282,8 @@ source files in a package, as far as is reasonably 
> possible.  [#]_
>  Restrictions on objects in source packages
>  --
>  
> -The source package must not contain any hard links,  [#]_ device special
> -files, sockets or setuid or setgid files.. [#]_
> +The source package must not contain device special files, sockets, or
> +setuid or setgid files. [#]_
>  
>  .. _s-debianrules:
>  
> @@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series`` for 
> any ``foo``.
> would be nice if the modification time of the upstream source would
> be preserved.
>  
> -.. [#]
> -   This is not currently detected when building source packages, but
> -   only when extracting them.
> -
> -   Hard links may be permitted at some point in the future, but would
> -   require a fair amount of work.
> -
>  .. [#]
> Setgid directories are allowed.

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

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

[Russ Allbery]

This patch from a while back is still waiting for one more second before
it can be merged for the next Policy release.  It previously got one
second from Wouter.  I revised the patch to mention the experimental suite
as well as the backports suites.

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

>From 6a4e1b261f5f5765fa164e4bfd063f67d40a9a47 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 | 61 +++--
 1 file changed, 45 insertions(+), 16 deletions(-)

diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 5074428..e8978af 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 interpreted
+specially by Debian autobuilders. 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,47 @@ 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 discard the dependencies after the first. This is
+done to give alternative dependencies a consistent interpretation that
+reduces the risk of inconsistencies between repeated builds. If, for
+example, the first-listed dependency would normally be available but is
+temporarily not installable, the autobuilder fails rather than install a
+subsequent dependency that may significantly change the behavior of the
+package.
+
+More specifically, Debian autobuilders perform the following
+transformation on alternative dependencies in the ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields:
+
+#. Discard any alternatives that are restricted to architectures that do
+   not match the host architecture.
+#. Discard any alternatives specifying different package names than the
+   now-first alternative. (Alternatives specifying the same package name
+   are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.)
+
+For example, an autobuilder for the ``amd64`` architecture would treat the
+following dependency::
+
+foo-special [armhf] | foo (<= 4) | foo (>= 4.2) | bar
+
+as if it were::
+
+foo (<= 4) | foo (>= 4.2)
+
+The normal effect is to use only the first alternative that is valid on
+the relevant architecture and fail if that alternative is not installable.
+
+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.
+
+The autobuilders for the Debian backports suite do not perform this
+transformation and instead use the same dependency resolution rules as
+normal package installations to choose which alternative dependency to
+install.
+
 .. _s-built-using:
 
 Additional source packages used to build the binary - ``Built-Using``
@@ -666,21 +710,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``, ``Build-Depends-Indep`` and
-   ``Build-Depends-Arch`` permit the use of alternative dependencies,
-   those are only used for the backports suite on the Debian autobuilders.
-   On the other suites, after reducing any architecture-specific restrictions
-   for the build architecture in question, all but the first alternative are
-   discarded except if the alternative is the same package name as the first.
-   The latter exception is useful to specify version ranges like
-   ``foo (rel x) | foo (rel y)``. This is to reduce the risk of inconsistencies
-   between repeated rebuilds.  While 

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

[Russ Allbery]

Here is an updated proposed change for this bug, incorporating Guillem's
suggestions.  It is ready for seconds.

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

>From 66175d3775f238a5ce3a2254388ad974e81d462f 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 | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 4bab7df..904fa52 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 ` (mandatory in some cases)
 
 -  :ref:`Architecture ` (mandatory)
 
@@ -292,7 +292,7 @@ The fields in this file are:
 
 -  :ref:`Changed-By `
 
--  :ref:`Description ` (mandatory)
+-  :ref:`Description ` (mandatory in some cases)
 
 -  :ref:`Closes `
 
@@ -812,10 +812,11 @@ 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
+the descriptions of the binary packages being uploaded. If no binary
+packages are being uploaded, this field will not be present. 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.
 
@@ -927,7 +928,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 no
+binary packages are being uploaded, this field will not be present.
 
 .. _s-f-Installed-Size:
 
-- 
2.40.1

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

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 18:16:07)
> Russ Allbery  writes:
> 
> > 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.
> 
> In the thread so far, there's been a bit of early convergence around my
> threshold of 100 packages above.  I want to make sure people realize that
> this is a very conservative threshold that would mean saying no to most
> new license inclusion requests.
> 
> My guess is that with the threshold set at 100, we will probably add
> around eight new licenses with the 25 line threshold (AGPL-2,
> Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
> OFL-1.1, and I'm not sure about some of those because the CC licenses have
> variants that would each have to reach the threshold independently; my
> current ad hoc script does not distinguish between the variants), and
> maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
> the BSD licenses).  This would essentially be continuing current practice
> except with more transparent and consistent criteria.  It would mean not
> including a lot of long legal license texts that people have complained
> about having to duplicate, such as the CDDL, CeCILL licenses, probably the
> EPL, the Unicode license, etc.
> 
> If that's what people want, that's what we'll do; as I said, that's what I
> would do if the choice were left entirely up to me.  But I want to make
> sure I give the folks who want a much more relaxed standard a chance to
> speak up.

Good point.

Another way of reading the responses is that there was some interest in
including even more licenses.

I would also prefer inclusion of more licenses, simply had the
impression that a) we could do that step by step, and b) my habit of
writing copyright files (and other teksts) using [semantic linebreaks]
made me forget that Expat license is arguably only 3 lines long (whereas
in my style of writing it is 24-25 lines long).

If "include all SPDX licenses" is for some reason (space in minimal
systems?) problematic, then let me propose a threshold of 1000
characters - as that just about covers Expat ;-)


 - Jonas


[semantic linebreaks]: https://sembr.org/

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

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

[Bill Allombert]

On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> > Quoting Hideki Yamane (2023-09-10 11:00:07)
> 
> >>  Hmm, how about providing license-common package and that depends on
> >>  "license-common-list", and ISO image provides both, then? It would be
> >>  no regressions.
> 
> I do wonder why we've never done this.  Does anyone know?  common-licenses
> is in an essential package so it doesn't require a dependency and is
> always present, and we've leaned on that in the past in justifying not
> including those licenses in the binary packages themselves, but I'm not
> sure why a package dependency wouldn't be legally equivalent.  We allow
> symlinking the /usr/share/doc directory in some cases where there is a
> dependency, so we don't strictly require every binary package have a
> copyright file.

Or we could generate DEBIAN/copyright from debian/copyright using data in
license-common-list at build time. So maintainers would not need to manage the 
copying
themselves.

Cheers,
Bill

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

[Russ Allbery]

Russ Allbery  writes:

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

In the thread so far, there's been a bit of early convergence around my
threshold of 100 packages above.  I want to make sure people realize that
this is a very conservative threshold that would mean saying no to most
new license inclusion requests.

My guess is that with the threshold set at 100, we will probably add
around eight new licenses with the 25 line threshold (AGPL-2,
Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
OFL-1.1, and I'm not sure about some of those because the CC licenses have
variants that would each have to reach the threshold independently; my
current ad hoc script does not distinguish between the variants), and
maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
the BSD licenses).  This would essentially be continuing current practice
except with more transparent and consistent criteria.  It would mean not
including a lot of long legal license texts that people have complained
about having to duplicate, such as the CDDL, CeCILL licenses, probably the
EPL, the Unicode license, etc.

If that's what people want, that's what we'll do; as I said, that's what I
would do if the choice were left entirely up to me.  But I want to make
sure I give the folks who want a much more relaxed standard a chance to
speak up.

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

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

[Russ Allbery]

Jonas Smedegaard  writes:
> Quoting Hideki Yamane (2023-09-10 11:00:07)

>>  Hmm, how about providing license-common package and that depends on
>>  "license-common-list", and ISO image provides both, then? It would be
>>  no regressions.

I do wonder why we've never done this.  Does anyone know?  common-licenses
is in an essential package so it doesn't require a dependency and is
always present, and we've leaned on that in the past in justifying not
including those licenses in the binary packages themselves, but I'm not
sure why a package dependency wouldn't be legally equivalent.  We allow
symlinking the /usr/share/doc directory in some cases where there is a
dependency, so we don't strictly require every binary package have a
copyright file.

>>  I expect license-common-list data as below
>> 
>>  license-short-name: URL
>>  GPL-2: file:///usr/share/common-licenses/GPL-2
>>  Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

> Ah, so what you propose is to use file URIs.

> I guess Russ' response above was a concern over using http(s) URIs
> towards a non-local resource.

Yes, I think the https URL is an essential part of the first proposal,
since it avoids needing to ship a copy of all of the licenses.  But I'm
dubious that would pass legal muster.

The alternative proposal as I understand it would be to haave a
license-common package that includes full copies of all the licenses with
some more relaxed threshold requirement and have packages that use one of
those licenses depend on that package.  (This would obviously require a
maintainer be found for the license-common package.)

> License: Apache-2.0
> Reference: /usr/share/common-licenses/Apache-2.0

This is separate from this particular bug, but I would love to see the
pointer to common-licenses turned into a formal field of this type in the
copyright format, rather than being an ad hoc comment.

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

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

[Russ Allbery]

Adam Borowski  writes:

> Agreed, but it might be good to say "it would be good to have this", and
> send a bug/mail to the relevant teams, asking if there are objections
> before anyone spends work to implement this.

> I for one have currently no less than three related ideas:
>  * this
>  * richer arch aliases (better than current dpkg aliases; could be
>implemented like shell foo-$@-bar word multiplication, thus linux-64bit
>would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind
>of shot before though
>  * replacing explicit arch names in source packages by facets (like:
>x86, little-endian, sse2, time64, ...) that are expanded at build time;
>procrastiplanning to propose this

> It's good to discuss such things -- if someone offers to implement such a
> change.

Yes, I agree.

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

> Could we oh so please have this as a policy policy in other cases, too?

Yes, historically I've been reluctant to close Policy bugs that indicate
real problems even if no apparent forward progress is being made on that
bug, but I'm starting to think this is too conservative and keeping really
old stalled bugs open is often not useful.  However, there are a lot of
bugs and I don't touch them very frequently, since I'm trying to focus on
closing bugs that do have forward progress.

If you or anyone else has a list of bugs that you think fall into that
category (no known efforts towards an implementation, Policy can't change
until that implementation happens), please do send a list.  (Feel free to
send that privately if you think it might be controversial.)  I'm happy to
take a look.

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

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

[Adam Borowski]

On Sat, Sep 09, 2023 at 02:53:00PM -0700, Russ Allbery wrote:
> Samuel Thibault  writes:
> > Architecture: !s390 !s390x
> > Architecture: !hppa !hurd-any !kfreebsd-any
> > 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.

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

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

Agreed, but it might be good to say "it would be good to have this",
and send a bug/mail to the relevant teams, asking if there are objections
before anyone spends work to implement this.

I for one have currently no less than three related ideas:
 * this
 * richer arch aliases (better than current dpkg aliases; could be
   implemented like shell foo-$@-bar word multiplication, thus linux-64bit
   would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind
   of shot before though
 * replacing explicit arch names in source packages by facets (like:
   x86, little-endian, sse2, time64, ...) that are expanded at build time;
   procrastiplanning to propose this

It's good to discuss such things -- if someone offers to implement such a
change.


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

Could we oh so please have this as a policy policy in other cases, too?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Elemental clouds:
⣾⠁⢠⠒⠀⣿⡁ • earth: cumulogranite (aviation)
⢿⡄⠘⠷⠚⠋⠀ • fire:  pyrocumulus (forestry, volcanism)
⠈⠳⣄ No known relations of clouds to air or water.

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

[Luca Boccassi]

On Sun, 10 Sept 2023 at 04:36, 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.

+1, great work and great starting point.

I also agree with Enrico and I'd like lower limits too, but any
progress is good progress on this matter for me.

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

[Luca Boccassi]

On Sun, 10 Sept 2023 at 11:31, Simon McVittie  wrote:
>
> On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
> > 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
>
> I'm not Luca, but I think you're correct here.

Moved as suggested. Also incorporated your suggestion on the versioned
virtual package dependency verbatim.

> > Luca Boccassi  writes:
> > > +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.
>
> In general tmpfiles.d handles files that exist only as metadata: symbolic
> links (for which the target is the only interesting fact), empty files
> (for which the existence and ownership/permissions are the only interesting
> facts), directories (ditto) and so on.
>
> It can also handle files that have static initial contents that do not
> vary between systems, but can change in a system-specific way later,
> with initial contents either hard-coded in the tmpfiles.d snippet (for
> short text strings) or copied from somewhere below /usr (canonically
> /usr/share/factory).
>
> Files generated by non-trivial imperative code, like machine-specific
> initial contents (/var/lib/dbus/machine-id) or some sort of compiler
> (/var/lib/gnubg/gnubg_ts0.bd, as far as I can tell), are out of scope for
> tmpfiles.d, so I think you're right to be concerned that Luca's wording
> as written is asking gnubg to do something that is unimplementable.
> ch-maintainerscripts.rst has the same issue.
>
> Perhaps "files with trivial contents that are located under /var" would be
> a good wording that is not overly specific about implementation details,
> covers the 90% case, and leaves room for exceptions by declaring packages
> like dbus and gnubg to be non-trivial?

I have reworded as suggested, citing symlinks or short fixed strings
as examples.

> If /var/lib/gnubg/gnubg_ts0.bd is deterministically compiled from
> files shipped in the .deb as a time/space trade-off, is only written
> during package management operations, and is otherwise read-only, then
> perhaps it should live in /usr, but that's orthogonal to wanting to use
> tmpfiles.d where feasible. (Prior art for similar situations includes
> Python bytecode, glibc locales, GLib gschemas.compiled and giomodule.cache,
> and so on.)

We don't have to handle it with this change/bug and as mentioned I've
already reworded it as suggested, but to clarify my thinking there,
the place I was coming from was the factory reset and first boot
angle. When doing a first boot with only the OS vendor tree under /usr
and nothing else, you want to get to a working system, and if there
are complex files created under /var by maintainer scripts, that's
kinda of a problem. This is where tmpfiles.d plus Credentials
(https://systemd.io/CREDENTIALS/ see examples toward the end
especially) can come in and help, even with non-trivial files, such as
users, passwords and ssh keys.
Perhaps those complex binaries should be created by oneshot services
that run at boot with a ConditionPathExists=!/var/some/complex/binary
other than maintainer scripts? That way if /var is blown away, you
still get a working system on next boot.

But again, happy to shelve this for now, as it's a more complex topic.
See attached file for new revision, also pushed to Salsa.
From  Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Tue, 9 May 2023 01:38:13 +0100
Subject: [PATCH] Define service directories and tmpfiles.d interfaces and
 usage

---
 policy/ch-files.rst | 49 +
 policy/ch-maintainerscripts.rst |  7 +
 policy/ch-opersys.rst   | 21 ++
 3 files changed, 77 insertions(+)

diff --git a/policy/ch-files.rst b/policy/ch-files.rst
index b34c183..7d0837c 100644
--- a/policy/ch-files.rst
+++ b/policy/ch-files.rst
@@ -722,6 +722,55 @@ 

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

[Simon McVittie]

In general I support this direction.

On Sun, 25 Jun 2023 at 16:55:44 +0100, Luca Boccassi wrote:
> Packages shipping ``tmpfiles.d`` snippets should
> +depend on the appropriate virtual packages in the following order:
> +``default-systemd-tmpfiles | systemd-tmpfiles``.

I think it's worth saying explicitly that if the package relies on
functionality added in systemd version n, where n is newer than some
reasonable cutoff, it should depend on
default-systemd-tmpfiles (>= n) | systemd-tmpfiles (>= n)
instead.

If a package is targeting testing/unstable, then it can drop the version
constraint in the very common case where its tmpfiles.d snippet is processed
correctly by stable's systemd-tmpfiles. Similarly if it's targeting stable,
it can drop the version constraint if oldstable's systemd would have been
enough.

Perhaps this?

Packages shipping ``tmpfiles.d`` snippets should
depend on the appropriate virtual packages in the following order:
``default-systemd-tmpfiles (>= v) | systemd-tmpfiles (>= v)``,
where *v* is a version of systemd that provides all ``tmpfiles.d``
features that are required. The version constraint may be
omitted if it is satisfied by all implementations of the
``systemd-tmpfiles`` virtual package supported in the previous stable
release.

(If debhelper generates the dependency, in practice it's probably enough
for it to generate the unversioned dependency, and in the rare case
where a tmpfiles.d snippet needs new features, maintainers can add
the versioned dependency themselves.)

smcv

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

[Luca Boccassi]

On Sun, 10 Sept 2023 at 03:19, Russ Allbery  wrote:
>
> 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".

Thank you, looks good to me, seconded.

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

[Simon McVittie]

On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
> 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

I'm not Luca, but I think you're correct here.

> Luca Boccassi  writes:
> > +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.

In general tmpfiles.d handles files that exist only as metadata: symbolic
links (for which the target is the only interesting fact), empty files
(for which the existence and ownership/permissions are the only interesting
facts), directories (ditto) and so on.

It can also handle files that have static initial contents that do not
vary between systems, but can change in a system-specific way later,
with initial contents either hard-coded in the tmpfiles.d snippet (for
short text strings) or copied from somewhere below /usr (canonically
/usr/share/factory).

Files generated by non-trivial imperative code, like machine-specific
initial contents (/var/lib/dbus/machine-id) or some sort of compiler
(/var/lib/gnubg/gnubg_ts0.bd, as far as I can tell), are out of scope for
tmpfiles.d, so I think you're right to be concerned that Luca's wording
as written is asking gnubg to do something that is unimplementable.
ch-maintainerscripts.rst has the same issue.

Perhaps "files with trivial contents that are located under /var" would be
a good wording that is not overly specific about implementation details,
covers the 90% case, and leaves room for exceptions by declaring packages
like dbus and gnubg to be non-trivial?

If /var/lib/gnubg/gnubg_ts0.bd is deterministically compiled from
files shipped in the .deb as a time/space trade-off, is only written
during package management operations, and is otherwise read-only, then
perhaps it should live in /usr, but that's orthogonal to wanting to use
tmpfiles.d where feasible. (Prior art for similar situations includes
Python bytecode, glibc locales, GLib gschemas.compiled and giomodule.cache,
and so on.)

smcv

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

[Hideki Yamane]

On Sat, 09 Sep 2023 20:35:27 -0700
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).


-- 
Hideki Yamane 

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

[Jonas Smedegaard]

Quoting Hideki Yamane (2023-09-10 11:00:07)
> On Sat, 09 Sep 2023 22:41:48 -0700
> Russ Allbery  wrote:
> > >  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).
> 
>  Hmm, how about providing license-common package and that depends on
>  "license-common-list", and ISO image provides both, then? It would be
>  no regressions.
> 
> 
>  I expect license-common-list data as below
> 
>  license-short-name: URL
>  GPL-2: file:///usr/share/common-licenses/GPL-2
>  Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

Ah, so what you propose is to use file URIs.

I guess Russ' response above was a concern over using http(s) URIs
towards a non-local resource.

What I practice since some years is the following syntax:

Files: foo/bar
Copyright:
  2022  Someone
License: Apache-2.0 or Expat

License: Apache-2.0
Reference: /usr/share/common-licenses/Apache-2.0

License: Expat
 [the full contents of the Expat license]

That syntax introduces a new field "Reference" (our copyright file
format permits new fields, despite lintian complaining about it).
Related discussion is at https://bugs.debian.org/786450


 - 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

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

[Marco d'Itri]

On Sep 10, Enrico Zini  wrote:

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

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

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Hideki Yamane]

On Sat, 09 Sep 2023 22:41:48 -0700
Russ Allbery  wrote:
> >  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).

 Hmm, how about providing license-common package and that depends on
 "license-common-list", and ISO image provides both, then? It would be
 no regressions.


 I expect license-common-list data as below

 license-short-name: URL
 GPL-2: file:///usr/share/common-licenses/GPL-2
 Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

-- 
Hideki Yamane 

Bug#991984: closed by Russ Allbery (Re: Bug#991984: Please document minimal environment variable needed for sensible-utils)

[Bastien Roucariès]

Le dimanche 10 septembre 2023, 04:33:06 UTC Debian Bug Tracking System a écrit :
> This is an automatic notification regarding your Bug report
> which was filed against the debian-policy package:
> 
> #991984: Please document minimal environment variable needed for 
> sensible-utils
> 
> It has been closed by Russ Allbery .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Russ Allbery 
>  by
> replying to this email.
> 
Seems sensible note that linux manpages mandate now some behavior for EDITOR, 
PAGER and VISUAL

Bastien



signature.asc
Description: This is a digitally signed message part.