Bug#1074014: encode mandatory merged-/usr into policy
Hello, On Thu 25 Jul 2024 at 03:12pm +02, Helmut Grohne wrote: > Can a policy editor follow up with instructions on where we are (from a > policy procedures point of view) and what needs to be done to move this > proposal forward? I'm focused on tag2upload right now. If Russ doesn't get to this soon, please ping again. -- Sean Whitton
Bug#1075856: Clarify filename conflicts for programs
Hello, On Sat 06 Jul 2024 at 07:49pm +02, Chris Hofstaedtler wrote: > I'm happy to file the bugs, if policy intended to forbid this, and/or > this bug does not get rejected. I would be happy to second this change too. Generally however we seek not to make packages buggy by releasing Policy. So it would be good to file those bugs first. -- Sean Whitton
Re: Why do we have both locales/ and policy/locale/ ?
Hello, On Wed 08 May 2024 at 08:04pm +02, Guillem Jover wrote: > Doing some brief checks now, it seems to confirm that locales/ > contains no major translations, while policy/locale/ does: > > for po in policy/locale/ja/LC_MESSAGES/*.po; do > echo "== $po ==" > msgfmt --output=/dev/null --statistics $po > done > > vs > > for po in locales/ja/LC_MESSAGES/*.po; do > echo "== $po ==" > msgfmt --output=/dev/null --statistics $po > done > > In addition, re-running the above msgfmt with --check, and also running > «i18nspector **/*.po», both emit multiple things that could be fixed, > or improved. Thanks for taking a look. I think I've successfully merged the two sets of .po files, now, on the next branch. -- Sean Whitton signature.asc Description: PGP signature
Why do we have both locales/ and policy/locale/ ?
Hello, 'make update-po' changes files under locales/. Our translators Hideki, Fei Ding and Ke Zhang work under policy/locale/. This seems wrong. As far as I can tell, when the English is updated, we are not updating the .po files that are actually being translated. Looking at % git log --stat -10 --author=henrich debian/4.2.0.1 shows that around the time when Hideki internationalised Policy, he was editing files under both directories. This suggests that it wasn't that Ian, Russ or I accidentally introduced a duplicate set of .po files when we were later working on the internationalisation. Does anyone know what's going on? The 'next' branch has the current state of play. -- Sean Whitton signature.asc Description: PGP signature
Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files
Hello,
On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote:
> From afac52fa956087eb737c123682f634fc739c7e20 Mon Sep 17 00:00:00 2001
> From: Guillem Jover
> Date: Tue, 27 Feb 2024 23:37:06 +0100
> Subject: [PATCH] =?UTF-8?q?Add=20references=20to=20=C2=ABdpkg-buildtree=20?=
> =?UTF-8?q?clean=C2=BB=20for=20debian/{substvars,files}?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> These files are generated by dpkg tools (and in some cases by helpers),
> but the maintainer was responsible for cleaning them up. There is now
> a new command that will take care of cleaning these (and any other
> future) files that the dpkg suite might end up generating, making their
> introduction easier as the responsibility to remove them shifts back
> where it belongs.
> ---
> policy/ch-source.rst | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 4307e89..2fb05cd 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -685,7 +685,7 @@ variables are also available.
>
> The ``debian/substvars`` file is usually generated and modified
> dynamically by ``debian/rules`` targets, in which case it must be
> -removed by the ``clean`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
>
> See :manpage:`deb-substvars(5)` for full details about source variable
> substitutions, including the format of ``debian/substvars``.
> @@ -725,8 +725,9 @@ building packages to record which files are being
> generated.
>
> It should not exist in a shipped source package, and so it (and any
> backup files or temporary files such as ``files.new``) [#]_ should be
> -removed by the ``clean`` target. It may also be wise to ensure a fresh
> -start by emptying or removing it at the start of the ``binary`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
> +It may also be wise to ensure a fresh start by emptying or removing it at the
> +start of the ``binary`` target.
>
> When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
> to ``debian/files`` for the ``.deb`` file that will be created when
Seconded.
It seems prudent to get reference to this tool into Policy as soon as
possible, even if we're not yet sure how it relates to debhelper.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files
Hello, On Sat 20 Apr 2024 at 09:00pm +02, Guillem Jover wrote: > Hi! > > On Thu, 2024-03-28 at 09:58:29 +0800, Sean Whitton wrote: >> On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote: >> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst >> > index 4307e89..2fb05cd 100644 >> > --- a/policy/ch-source.rst >> > +++ b/policy/ch-source.rst >> > @@ -685,7 +685,7 @@ variables are also available. >> > >> > The ``debian/substvars`` file is usually generated and modified >> > dynamically by ``debian/rules`` targets, in which case it must be >> > -removed by the ``clean`` target. >> > +removed by the ``clean`` target (for example with ``dpkg-buildtree >> > clean``). >> > >> > See :manpage:`deb-substvars(5)` for full details about source variable >> > substitutions, including the format of ``debian/substvars``. >> > @@ -725,8 +725,9 @@ building packages to record which files are being >> > generated. >> > >> > It should not exist in a shipped source package, and so it (and any >> > backup files or temporary files such as ``files.new``) [#]_ should be >> > -removed by the ``clean`` target. It may also be wise to ensure a fresh >> > -start by emptying or removing it at the start of the ``binary`` target. >> > +removed by the ``clean`` target (for example with ``dpkg-buildtree >> > clean``). >> > +It may also be wise to ensure a fresh start by emptying or removing it at >> > the >> > +start of the ``binary`` target. >> > >> > When ``dpkg-gencontrol`` is run for a binary package, it adds an entry >> > to ``debian/files`` for the ``.deb`` file that will be created when >> >> Instead of "It may also be wise ..." can you use one of the sets of >> magic words from Policy 1.1, please? > > This text was already part of policy and the proposed patch did not > really touch it, except for wrapping it into a new line. I think > modifying it feels a bit out-of-scope for this request? But if you > think it's relevant, and the sentence should be improved as part of > this, then I'll try to provide some wording. :) Ah yes, sorry, that is indeed out-of-scope. -- Sean Whitton signature.asc Description: PGP signature
Re: single-page html of debian-policy to be revived?
Hello, On Mon 15 Apr 2024 at 09:59am GMT, Holger Levsen wrote: > On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote: >> ... but if dev-ref is already shipping both, maybe singlepage is indeed >> usable these days ... > > I think it is. > >> > Could the Policy Editors team check, if everything is fine now, and if >> > this should be published again? >> > At least there is still an issue with the footnotes, there are 16 >> > occurrences >> > of #id1 for example... (search for "[1]" in policy-1.html). >> Hrm. That seems like a pretty serious problem :\ > > I wouldnt call it serious. annoying yes, maybe. > >> Holger L., did you know about this issue? >> Did you decide it was worth publishing anyway? > > yes. > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages > or (single page) > https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages > both show four footnotes, right where they belong, it's just that > each foot note is numbered and that [1] or [2] or whatever is > a link, pointing to a wrong place. > > I agree it's a bug, but I do think it's a pretty harmless one. Thanks. I'd be grateful for some feedback from other regular Policy contributors. -- Sean Whitton signature.asc Description: PGP signature
Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
Hello Go and Rust packagers, On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote: > With the increasing amount of programs in Debian that Build-Depend and > statically link with Golang and Rust libraries, it's important that > the Debian Policy clearly sets out the requirements for declaring > these statically-linked libraries. I think Maytham is right that updating Policy for this is a priority. It has been bothering me that misunderstandings of Built-Using have been proliferating somewhat among newer contributors. See also #999785. Could you take a look at his proposed changes to Policy in #1069256, please, and confirm they successfully reconcile Debian Policy with your team policies? I think that we should also include an explanation of why we have chosen to do this using a new field in d/control like Static-Built-Using. Policy is meant to be a record of our lessons learned in building a distribution, and the lessons learned in trying to handle these new hyper-statically linked language ecosystems seem important. My immediate question is why the Haskell and OCaml team's approaches, were not copied. They seem to work well and don't require a new field. That seems worth writing down. Thank you Maytham for your work so far. -- Sean Whitton signature.asc Description: PGP signature
Re: single-page html of debian-policy to be revived?
Hello, On Sun 14 Apr 2024 at 01:57pm +02, Holger Wansing wrote: > 1. > Currently, the package does not ship this version. So this would have to > be re-added there. The changelog for 4.2.0.0 says * Stop installing policy-1.html because Sphinx's singlehtml output is too buggy at present (Closes: #873456, #876075, #879048). See also #877367. Thanks to Paul Wise for switching the web mirrors away from policy-1.html. I had forgotten about this. It seems that the first thing to do would be to determine if the issues discussed in those bugs still exist. > 2. > There are pro's and con's for both the single-page and multi-page variants. > Thus the only possible way IMO is to ship both via www.d.o. > The developers-refererence also ships both already, so it would be consistent > there. ... but if dev-ref is already shipping both, maybe singlepage is indeed usable these days ... > Could the Policy Editors team check, if everything is fine now, and if > this should be published again? > At least there is still an issue with the footnotes, there are 16 occurrences > of #id1 for example... (search for "[1]" in policy-1.html). Hrm. That seems like a pretty serious problem :\ Holger L., did you know about this issue? Did you decide it was worth publishing anyway? -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors
Hello, On Thu 11 Apr 2024 at 08:32am GMT, Holger Levsen wrote: > On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote: >> A single page html may be an additional option but there's already the >> single page txt version and the PDF. That's sufficient and I see no >> need in providing more formats of this manual. >> >> Therefore we can close this and I will close 877337. > > fwiw, I disagree with this conclusion. single page txt and pdf versions > are no replacements for single page html. I agree, and still think we should be publishing the single page version. -- Sean Whitton signature.asc Description: PGP signature
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Hello, On Sun 07 Apr 2024 at 08:54am +02, Paul Gevers wrote: > Hi, > > On Sat, 09 Sep 2023 18:51:52 -0700 Russ Allbery wrote: > > """ > +``systemd`` uses dependency and ordering information contained within the > ++enabled unit files to decide which services to run and in which order. > """ > ^ is that "+" before "enabled" really intended? It looks weird to me. Fixed in git, thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#963524: fixed in debian-policy 4.7.0.0
Hello, On Sun 07 Apr 2024 at 08:44am +02, Petter Reinholdtsen wrote: > For the record, and as stated in https://bugs.debian.org/999598 >, > I would rather have the description lines back in the changes file to > provide the information in the emails presenting uploads, instead of > dropping them. I guess this bug report will be closed unsolved instead. In this case we weren't really making a decision on the Policy side, but just updating documentation. So it can be changed back if the decision is reversed. -- Sean Whitton
debconf BoF idea
Hello Holger, I was thinking that maybe we could submit a joint Policy--DevRef BoF for debconf, if you are going to be there. -- Sean Whitton
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Hello, On Sat 06 Apr 2024 at 12:15pm +08, Sean Whitton wrote: > Hi Russ, > > We have two seconded solutions, so you and I should perhaps break the > tie. I prefer the Bill's 'Autobuild: no' solution as the more > conservative change: we only have data about packages that are currently > autobuilt, not those that aren't, so we might be making those buggy if > we just ban network access for all non-free packages. How about you? (It's not actually a tie in terms of number of seconds, but we don't do this quantatively.) -- Sean Whitton signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Hi Russ, We have two seconded solutions, so you and I should perhaps break the tie. I prefer the Bill's 'Autobuild: no' solution as the more conservative change: we only have data about packages that are currently autobuilt, not those that aren't, so we might be making those buggy if we just ban network access for all non-free packages. How about you? -- Sean Whitton signature.asc Description: PGP signature
Bug#1068022: Document the Testsuite-Triggers field
Hello, On Fri 05 Apr 2024 at 11:30am +02, Christian Kastner wrote: > Hi again, > > On 2024-03-29 20:30, Christian Kastner wrote: >> Policy 5.6.30 lists the Testsuite field, but it doesn't list the >> Testsuite-Triggers field that seems to be part of Sources files and is >> generated by dpkg-source >= 1.18.8. >> >> This field is quite useful, as given my package src:foo, I can find out >> which packages have autopkgtests that depend on it, and are thus in the >> set of reverse dependencies that I could check for breakage. > > I've read up on the change process [1], and I guess my proposal to > submit a patch was too far into the process. > > Thus, I take a step back, and seek discussion first. > > In addition to what I've said above, I think documenting this field > would not only enhance discoverability, but give more weight to it for > tooling that makes use of these fields. > > For discussion context, I'd like to quote dsc(5) on this field: >> Testsuite-Triggers: package-list >> >> This field declares the comma-separated union of all test dependencies >> (Depends fields in debian/tests/control file), with all restrictions >> removed, and OR dependencies flattened (that is, converted to separate AND >> relationships), except for binaries generated by this source package and its >> meta-dependency equivalent @. >> >> Rationale: this field is needed because otherwise to be able to get the test >> dependencies, each source package would need to be unpacked. Sounds good to me. If you'd like to propose wording, there's some more guidance in our README.md. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Hello, On Tue 02 Apr 2024 at 04:18pm +01, Josh Triplett wrote: > Sean Whitton wrote: >> On Tue 26 Mar 2024 at 10:11am -06, Sam Hartman wrote: >> > I tend to agree with Sean that your rationale is not convincing. >> > It sounds like you want to use policy as a stick to hit people >> > over the head and say "policy is not a stick." >> >> This was basically my concern. > > This feels like a painful mischaracterization of what I said. I don't > want to use policy as a stick. I want to make policy less usable as a > stick. I'm sorry, I didn't mean to be pejorative. I was meaning to say something more like "you can't fight fire with fire", rather than saying you actively wanted to use Policy like a stick. I'm sorry I was so terse. -- Sean Whitton
Bug#1064593: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello, On Mon 01 Apr 2024 at 02:50pm +02, Holger Wansing wrote: > I now tend to switch to another approach (also proposed similarly by Adam): > > instead of relying on the rtd-theme package in the default install path of the > package installed by DSA, I will use the infrastructure in 1ftpfiles and > 7doc of webmaster's cron repo, to (always) fetch the latest version of that > package (and two more packages, which the former depends on: > fonts-font-awesome > and fonts-lato, to get the needed fonts) and unpack+copy them into > a dedicated path inside the www build tree. > > That path will be synced to the static www mirrors, and we can symlink > to it from the manuals. > (And the content of that path will automatically be kept up-to-date on > the unstable version of packages, so we don't get outdated/orphaned > copies of that packages in the isolated path.) > I want the unstable version of that packages here, since they need to > incorporate with the unstable version of the different manuals (like > debian-policy), and those packages are built by buildd, so unstable. > > How does that sound in the light of Debian guidelines and best practice? > > Is it ok, to have such "isolated copies" of packages as described above? > > I have not much experience in similar things, so I would like to get > some comments here, please. I mean, it seems okay to me, but it's up to the web team really. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Hello, On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > Package: debian-policy > Version: 4.6.2.1 > Severity: normal > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > Control: affects -1 buildd.debian.org > > Hi, > > The debian policy, section 4.9, forbids network access for packages in > the main archive, which implicitly means they are authorized for > packages in contrib and non-free (and non-free-firmware once #1029211 is > fixed). > > This gives constraints on the build daemons infrastructure and also > brings some security concerns. Would it be possible to extend this > restriction to all archives? We need to know if this is going to break existing packages and allow some input from their maintainers. Are you able to prepare a list of the affected packages? -- Sean Whitton
Bug#1068022: Document the Testsuite-Triggers field
Hello, On Fri 29 Mar 2024 at 08:30pm +01, Christian Kastner wrote: > Package: debian-policy > Version: 4.6.2.0 > Severity: wishlist > > Policy 5.6.30 lists the Testsuite field, but it doesn't list the > Testsuite-Triggers field that seems to be part of Sources files and is > generated by dpkg-source >= 1.18.8. > > This field is quite useful, as given my package src:foo, I can find out > which packages have autopkgtests that depend on it, and are thus in the > set of reverse dependencies that I could check for breakage. > > I'd provide a patch based on the documentation in dsc(5), but I don't > know what the current process is. Does anyone have a link to a doc on > how to submit a change? There is a chapter of Policy regarding the Policy Changes Process. -- Sean Whitton signature.asc Description: PGP signature
Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files
Hello, On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote: > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index 4307e89..2fb05cd 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -685,7 +685,7 @@ variables are also available. > > The ``debian/substvars`` file is usually generated and modified > dynamically by ``debian/rules`` targets, in which case it must be > -removed by the ``clean`` target. > +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``). > > See :manpage:`deb-substvars(5)` for full details about source variable > substitutions, including the format of ``debian/substvars``. > @@ -725,8 +725,9 @@ building packages to record which files are being > generated. > > It should not exist in a shipped source package, and so it (and any > backup files or temporary files such as ``files.new``) [#]_ should be > -removed by the ``clean`` target. It may also be wise to ensure a fresh > -start by emptying or removing it at the start of the ``binary`` target. > +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``). > +It may also be wise to ensure a fresh start by emptying or removing it at the > +start of the ``binary`` target. > > When ``dpkg-gencontrol`` is run for a binary package, it adds an entry > to ``debian/files`` for the ``.deb`` file that will be created when Instead of "It may also be wise ..." can you use one of the sets of magic words from Policy 1.1, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello,
On Fri 22 Mar 2024 at 06:46pm +03, Dmitry Shachnev wrote:
> Actually, I would move ${sphinxdoc:Depends} from Recommends to
> Depends, because the documentation is mostly unusable without the
> static files.
I think it's in Recommends because we ship other formats that don't need
it, and to ensure installability on stable, or something similar.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello, On Sat 23 Mar 2024 at 05:08pm +01, Holger Wansing wrote: > While working on adapting the parts/7doc script (from Debian Webmaster > Team's 'cron' repo), I realized that this is not going to work out of the > box: while the concept of the symlinks mentioned above is working fine, > when the debian-policy document is installed on a machine as usual > (means it recides in the same path as in the binary deb package, aka > /usr/share/doc/debian-policy/policy.html), we have the docs for the website > on the debian.org website machine in another path. That is in > /srv/www.debian.org/www/doc/debian-policy/. > > That means the (relative) symlinks will not resolve! > Therefore I think the best solution here is, to change the relative > symlinks into absolute ones, on the debian.org website machine. > > I have worked out the needed changes for cron/parts/7doc to deal with all > this (it works fine here locally). The debian-policy package could stay > unchanged. > I attach the patch here just for reference; will apply it, as soon as > sphinx-rtd-theme-common gets installed on wolkenstein > (working on a bugreport to DSA to get this done). > > Closing #1066967 against sphinx-common/dh_sphinxdoc now. > Thanks python people for your help! Many thanks all for working on this, especially you Holger for this scripting work. So, we're waiting in DSA and then on your script changes, and it'll work again. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Hello, On Tue 26 Mar 2024 at 10:11am -06, Sam Hartman wrote: >>>>>> "Josh" == Josh Triplett writes: > > > > I tend to agree with Sean that your rationale is not convincing. > It sounds like you want to use policy as a stick to hit people > over the head and say "policy is not a stick." This was basically my concern. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067155: debian-policy: prerm scripts cannot actually rely on dependencies
Hello, On Tue 19 Mar 2024 at 01:02pm +01, Julian Andres Klode wrote: > Package: debian-policy > Severity: wishlist > X-Debbugs-Cc: de...@lists.debian.org, debian-d...@lists.debian.org > > APT's installation planner does not consider dependencies of packages > being scheduled for removal, so a prerm must fail equally gracefully > as a postrm does in absence of its dependencies. > > This does break dpkg's assumptions which it happily tells you about, > but this is the reality we live in. > > So e.g. one thing you see is that apt removes libapt-pkg6.0, then > unpacks libapt-pkg6.0t64, then removes libapt-pkg6.0 reverse > dependencies. > > Clearly APT should be considering dependencies when removing packages > but even in that case, removals may sometimes need to be forced in the > wrong order because any order leads to broken dependencies, so still, > prerms should not rely on dependencies, but only on essential packages. I'm not sure that Policy is the place to discuss a change proposal like this, and we can't render a swathe of packages RC buggy by making such a change here. The archive would need to change first. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Hello, On Mon 18 Mar 2024 at 04:06am -07, Josh Triplett wrote: > On Mon, Mar 18, 2024 at 05:38:15PM +0800, Sean Whitton wrote: >> Was there some recent packaging situation that prompted you to think >> about this? I'm cautious about adding it in the absence of that. > > Mostly, recent discussions in various places regarding whether packages > are required to use *cron* to run periodic jobs. Policy says what > packages must do if they install a cronjob, but that itself does not > mandate the use of cron specifically. It seemed worth explicitly stating > the understood-but-unwritten interpretation that having Policy about XYZ > does not mandate that packages use XYZ. > > I've also seen a few arguments over the decades that amount to "Policy > talks about A, and doesn't talk about B" being used as some amount of > weight towards A or against B. > > And finally, I have occasionally seen someone try to build a Debian > package by sitting down with the Policy manual, and start down the route > of trying to supply everything Policy talks about that seems like it > makes sense for the package. The mention of "Policy talking about where > to install info documentation, but that doesn't mean you have to have > info documentation" was not a hypothetical; I've seen that and similar > reasoning a non-zero number of times. > > I figured that something like this text would help address all of those. Thanks. For the time being, I myself am not convinced. Policy is not a stick to beat maintainers with, as we say, but I'm not sure that idea is one that ought to be in Policy itself. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Hello Josh, Was there some recent packaging situation that prompted you to think about this? I'm cautious about adding it in the absence of that. -- Sean Whitton
Bug#1064593: debian-policy: missing static resources for www.debian.org policy page
Hello, On Sun 25 Feb 2024 at 02:24pm +01, Holger Wansing wrote: > Seems there is more than only one issue: > > 1. > In the binary package (debian-policy latest version) the above files and > directories are existing, but the files are all empty (0 B size). > However, in the previous version (4.6.2.0) the javascript .js files > are also empty (0 B), so that's most probably not the issue. > I remember we don't have full javascript functionality in our sphinx-based > manuals on debian.org for a longer time, search is not working for example. > That's #1026446, #872944, #987943. > > In a local build here, they are all fine, and the document is displayed > correctly. But that's build on bookworm, so sphinx version 5.3.0. > The binary packages built by buildd will get build on sphinx 7.2.x > I think, so maybe there is the difference? > Maybe we need some adaption for latest sphinx version? > > > 2. > The first file from above list _static/css/theme.css is likely to be > the point, since the html layout is completely broken. > That file is also empty in latest debian-policy binary package. > Since it is fine in local build here, also an issue with latest sphinx > version maybe ??? > Or do we no longer need _static/css/theme.css, as we now have > _static/debian.css ? > > > 3. > Despite the fact, that the files from above are empty, there seems to be > another issue with debian.org website: > the subdirectories under _static are not existing on debian.org, as well as > the files within of course (like _static/css/theme.css). > Apparently there is some more magic needed in webmaster-team's cron > https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7doc?ref_type=heads#L319 > to get such files copied over to debian.org during website build. > > But first, we need to have a working version in the binary package, > since that's the basis for website build. I guess I should have done a debdiff huh? :) Thank you for the analysis. Osamu, Stéphane, could you take a look? Thank you. -- Sean Whitton
Bug#1064593: debian-policy: missing static resources for www.debian.org policy page
Hello, On Sun 25 Feb 2024 at 08:44am +01, Holger Wansing wrote: > Hi, > > Am 24. Februar 2024 20:15:41 MEZ schrieb James Addison : >> >>(this may relate closely to #915583) >> >>Some of the web resources referenced by the online[1] copy of the Debian >>policy >>manual seem to return HTTP 404 responses at the moment, meaning that the >>intended Sphinx CSS theming fails to apply. >> >>[1] - https://www.debian.org/doc/debian-policy/ > > Hmm, locally built it's fine here ... > > @Stéphane: could you take a look? The new debian.css is there. So, which file is it that's missing? -- Sean Whitton
Bug#915583: about html_static_path
control: tag -1 + pending Hello, On Sat 24 Feb 2024 at 08:52am +01, Holger Wansing wrote: > Hi Sean, > > Sean Whitton wrote (Sat, 24 Feb 2024 11:58:59 > +0800): >> Attached is the patch I prepared, which I couldn't get to work. Maybe >> you can see what is wrong. Thanks! > > As I know it, the debian.css file has to reside in policy/_static. > And activate (un-comment) the path declaration for that in line 105 of > conf.py.in. > > Additionally, as I already wrote somewhere, for navigating it would be good > to have the Next/Previous buttons at the top of the page as well, not only > at the bottom. > > And: do we want to have the > "Built with Sphinx using a theme provided by Read the Docs." > in the footer? If not, that could be suppressed by > html_show_sphinx = False > in conf.py.in. > > > My diff for conf.py.in would be like this (with above suggestions): Thank you very much, both -- now merged for the next upload. -- Sean Whitton signature.asc Description: PGP signature
Bug#915583: about html_static_path
Hello,
On Thu 15 Feb 2024 at 11:44pm +01, Holger Wansing wrote:
> Sean Whitton wrote:
>> On Fri 29 Dec 2023 at 07:08am +01, Stéphane Blondon wrote:
>>
>> > Yes, html_static_path must be set but it's already the case in conf.py.in:
>> > https://sources.debian.org/src/debian-policy/4.6.2.0/policy/conf.py.in/#L105
>> >
>> > I guess conf.py is generated from conf.py.in so we only need to keep
>> > the current setup.
>>
>> That line is commented out, though. Are you saying it takes on its
>> default value in that case?
>
> I think it would be good to un-comment such lines which are needed, so it's
> clear without doubt, what is used and active.
> Works fine here BTW.
Attached is the patch I prepared, which I couldn't get to work. Maybe
you can see what is wrong. Thanks!
-- >8 --
From: =?UTF-8?q?St=C3=A9phane=20Blondon?=
Date: Mon, 27 Nov 2023 23:36:06 +0100
Subject: [PATCH] New Debian-specific Sphinx style
---
debian/changelog | 3 ++
debian/control| 1 +
policy/conf.py.in | 5 ++-
policy/debian.css | 103 ++
4 files changed, 111 insertions(+), 1 deletion(-)
create mode 100644 policy/debian.css
diff --git a/debian/changelog b/debian/changelog
index ffa0f8b..6d04491 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,9 @@ debian-policy (4.6.2.1) UNRELEASED; urgency=medium
package metadata.
* Update Installed-Size algorithm used by dpkg (Closes: #793499).
+ [ Stéphane Blondon ]
+ * New Debian-specific Sphinx style (Closes: #915583).
+
-- Russ Allbery Sat, 09 Sep 2023 15:27:27 -0700
debian-policy (4.6.2.0) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index a98b425..ebb3c3f 100644
--- a/debian/control
+++ b/debian/control
@@ -17,6 +17,7 @@ Build-Depends:
libxml2-utils,
links | elinks,
python3-sphinx,
+ python3-sphinx-rtd-theme,
sphinx-common (>= 1.6.5),
sphinx-intl,
texinfo,
diff --git a/policy/conf.py.in b/policy/conf.py.in
index d516d7b..86bc1ac 100755
--- a/policy/conf.py.in
+++ b/policy/conf.py.in
@@ -84,7 +84,7 @@ todo_include_todos = False
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
#
-html_theme = 'nature'
+html_theme = 'sphinx_rtd_theme'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
@@ -92,6 +92,9 @@ html_theme = 'nature'
#
# html_theme_options = {}
+# Overwrite theme to fit Debian colors
+html_css_files = ['debian.css']
+
# Override the title to remove the unnecessary "documentation" suffix.
html_title = "Debian Policy Manual v@VERSION@"
diff --git a/policy/debian.css b/policy/debian.css
new file mode 100644
index 000..7f0981b
--- /dev/null
+++ b/policy/debian.css
@@ -0,0 +1,103 @@
+/* Debian Cascading stylesheet for Sphinx */
+
+div.related {
+background-color: #C70036;
+}
+
+.rst-content h1, .rst-content h2, .rst-content h3, .rst-content h4,
.rst-content h5, .rst-content h6 {
+color: #C70036;
+}
+
+.wy-nav-top {
+background-color: #C70036;
+}
+
+.wy-side-nav-search {
+background-color: #C70036;
+}
+
+.rst-content a:link {
+color: #0035C7;
+text-decoration: none;
+}
+.rst-content a:visited {
+color: #00207A;
+text-decoration: none;
+}
+.rst-content a:link:hover {
+color: #00207A;
+text-decoration: underline;
+}
+
+
+/* Table in content */
+
+.wy-table-responsive table td, .wy-table-responsive table th {
+white-space: normal;
+}
+
+.rst-content table.docutils, .wy-table-bordered-all {
+width: 100%;
+}
+
+.wy-table-responsive table.docutils thead tr {
+background-color: #C70036;
+border: 1px solid black;
+color: black;
+}
+
+.wy-table-responsive table.docutils thead tr:hover {
+color: #fcfcfc;
+}
+
+.wy-table-responsive table.docutils tbody tr:hover {
+background-color:#66;
+color: #FF;
+}
+
+.rst-content table.docutils:not(.field-list) tbody tr:hover:nth-child(2n-1),
.wy-table-backed, .wy-table-odd td, .wy-table-striped tr:nth-child(2n-1) td {
+background-color:#66;
+}
+
+/* Previous and next buttons */
+
+.rst-footer-buttons .btn:hover {
+text-decoration: none !important;
+}
+
+/* Version release more readable */
+
+.wy-side-nav-search > div.version {
+color: #FCFCFC;
+}
+
+/* Infos blocks */
+
+div.warning {
+border: 1px dashed #EFF500;
+background-color: #eff50030;
+}
+
+div.note {
+border: 1px dashed blue;
+background-color: #ff30;
+
+}
+
+.warning, .note {
+margin-left: 1em;
+margin-right: 1em;
+}
+
+@media (max-width: 5in), (max-device-width: 5in){
+.warning, .note {
+margin-left: 0.5em;
+margin-right: 0.5em;
+}
+}
+
+/* Notes */
+
+html.writer-html5 .rst-content aside.citation, html.writer-html5 .rst-content
aside.footn
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
ll also want to minimise how much it gets in the way of people who have no interest in that sort of feature -- most of our classic Debian desktop power users, I suspect (which includes most DDs). Russ, I think there are some changes to your most recent wording you intended to make after feedback from Simon, but I don't think you've posted an updated patch yet? If you could, I can review and second. I think what you write in your patch is fair to proponents of alternative init systems, though it would be good to have explicit approval from one of them if someone has time. We could post your updated patch to one of their lists? Thank you for your efforts on this. -- Sean Whitton signature.asc Description: PGP signature
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
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 this may limit the usefulness of > - alternatives in a single release, they can still be used to provide > - flexibility in building the same package across multiple > - distributions or releases, where a particular dependency is met by > - differently named packages. > - > .. [#] > The relations ``<`` and ``>`` were previously allowed, but they were > confusingly defined to mean earlier/later or equal rather than -- Sean Whitton
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
Hello, On Mon 11 Sep 2023 at 01:04pm +02, Santiago Vila wrote: > I wrote: >> I believe that by choosing the wording appropriately, we can still keep this >> desired property of Policy while still not mandating any given >> implementation. > > Sorry, that was terribly worded. I meant that we can avoid the hassle of > documenting everything dh_installsystemd does and at the same time not > *formally* mandating the use of dh_installsystemd. In general, I agree with Santiago. I find Policy's current scope and working process effective, and not especially ambiguous. I think everyone should read it during the NM process, if not sooner. Russ has concretely considered these issues much more than me, and Niels has worked extensively on an implementation, and I have not. These things count, so my sense that things are broadly okay as they are only goes so far. I do think we should put weight on our actual experiences as Debian contributors, and what's useful, and, as elsewhere in software, focus on incremental improvements over rewrites. For example, I think that the knowledge of good documentation practices that's already implicit in how we all actually write Policy text counts for more than abstract discussions of best practice. -- Sean Whitton signature.asc Description: PGP signature
Bug#915583: about html_static_path
Hello, On Fri 29 Dec 2023 at 07:08am +01, Stéphane Blondon wrote: > Yes, html_static_path must be set but it's already the case in conf.py.in: > https://sources.debian.org/src/debian-policy/4.6.2.0/policy/conf.py.in/#L105 > > I guess conf.py is generated from conf.py.in so we only need to keep > the current setup. That line is commented out, though. Are you saying it takes on its default value in that case? -- Sean Whitton signature.asc Description: PGP signature
Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST
Hello, On Sat 30 Dec 2023 at 11:11pm +01, Holger Wansing wrote: > Source: debian-policy > Tags: patch > > Debian Policy has been migrated to restructedText / Sphinx. > However, the current html theme is not conform with the look of the Debian > website. > > Bug #1053549 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053549) > requests to create a new theme for Sphinx-based documents "to match our docs > appearance with the Debian website colours etc." > > I have worked on this and a patch is attached, to fulfill this goal. > > An preview how the Debian Policy would look like with this theme can be found > at > https://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/debian-policy-manual/ > > Please consider to apply this proposal. We're actually in the middle of applying someone else's proposal, here: #915583. Possibly some of your changes could be applied on top of that? -- Sean Whitton signature.asc Description: PGP signature
Bug#1057238: debian-policy: Take dpkg-build-api into account for Rules-Requires-Root
Hello, On Sat 02 Dec 2023 at 01:22am +01, Guillem Jover wrote: > Starting with dpkg 1.22.0, it implements a dpkg-build-api mechanism > similar in concept to the debhelper-compat levels. > > You can check its documentation in the dpkg-build-api(7) and > dpkg-buildapi(1) manual pages. > > I think at least the part that involves the Rules-Requires-Root field > which in level 1 defaults to value «no» instead of «binary-targets» > should be documented in the Debian policy. Agreed. Thanks for the report. > I'm ambivalent on whether documenting the general mechanism in Debian > policy makes sense though. When many/most Debian package maintainers need to know about this, as they do debhelper compat, then we should add it, but until then, perhaps not. -- Sean Whitton signature.asc Description: PGP signature
Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks
Hello, On Fri 01 Dec 2023 at 02:11pm +01, Helmut Grohne wrote: > §7.4 currently starts with: > > When one binary package declares a conflict with another using a > Conflicts field, dpkg will refuse to allow them to be unpacked on > the system at the same time. > > I believe this is technically wrong. There are situations where dpkg > will allow such unpacks to temporarily co-exist. §6.6 goes into further > detail and is accurate. Thank you for the detailed report. Do the dpkg and apt people think that the bug here is just in Policy, or are there any code changes under consideration in response to this work? -- Sean Whitton signature.asc Description: PGP signature
Bug#915583: patch for debian style
Hello, On Mon 27 Nov 2023 at 11:36pm +01, Stéphane Blondon wrote: > Hello, > > the attached file (debian.css) sets up the custom style. > > In order to work: > - add the 'python3-sphinx-rtd-theme' package to the dependencies > - in `conf.py.in`, replace: >html_theme = 'nature' >by >html_theme = 'sphinx_rtd_theme' > > The generated conf.py file must contain: > # Overwrite theme to fit Debian colors > html_css_files = ['debian.css'] > > > Please tell me if it does not work because I made several workarounds > in order to get it work without everything properly > installed/configured. This doesn't seem to be enough to ensure that debian.css gets installed to the .deb. I think we might also need to set html_static_path ? -- Sean Whitton signature.asc Description: PGP signature
Bug#915583: debian sphinx styling: second attempt
Hello Stéphane, Thank you for working on this. A couple of things I have written in my notes, from years ago, on this topic: - it would be good for footnote references to stand out more than they do at present. I think your theme achieves this. - it would be good to do some accessibility testing of some kind, at least with screenreaders. But maybe the fact that you've based your theme on an existing, popular Sphinx theme means this is covered? Thanks again. -- Sean Whitton signature.asc Description: PGP signature
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Hello Russ, Thank you for working on this. On Sat 09 Sep 2023 at 08:35pm -07, Russ Allbery wrote: > 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. Something that hasn't been brought up yet is the effects on NEW review. I would like to expand the idea of the same license wording being used by all works, to include the additional requirement that there aren't any very similar licenses that are easily confused with the license. For, if it's a license with small variations of any kind, including variations that are not project-specific things like the names of copyright holders, then NEW review is much easier if all the text is right there in d/copyright. I would be in favour of the 25 lines criterion. The main problem with manipulating d/copyright is only the really long licenses, IME. -- Sean Whitton signature.asc Description: PGP signature
Bug#1024367: In 4.9.1, the example uses not recommended install -s
Hello, On Sat 09 Sep 2023 at 03:16pm -07, Russ Allbery wrote: > 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) <https://www.eyrie.org/~eagle/> > >>From 409bbd815a946a7bb7b1eea8cab8198c494dd7d4 Mon Sep 17 00:00:00 2001 > From: Russ Allbery > Date: Sat, 9 Sep 2023 15:10:21 -0700 > Subject: [PATCH] Remove old Makefile DEB_BUILD_OPTIONS example > > The correct way to implement most DEB_BUILD_OPTIONS these days is > to just use debhelper. The detailed Makefile fragment was probably > more confusing than helpful, given that it predates dpkg-buildflags, > uses install -s (which Policy elsewhere recommends against), and > manually does other work debhelper would automate. Replace it with > a note that packaging helper frameworks do much of this work. > --- > policy/ch-source.rst | 35 +++---- > 1 file changed, 3 insertions(+), 32 deletions(-) LGTM. -- Sean Whitton signature.asc Description: PGP signature
Bug#1041464: debian-policy: make Uploaders field optional for team-maintained packages
Hello, On Wed 19 Jul 2023 at 10:48am +01, Luca Boccassi wrote: > Thanks, I skimmed through that long discussion and it seems to me it > went nowhere. I don't think there's any benefit in attempting to just > restart it. What about escalating to the CTTE and ask them to make a > decision? That way the matter can be closed one way or the other. That would be a premature escalation -- if you want to drive this, please approach the MIA team. -- Sean Whitton
Bug#1041464: debian-policy: make Uploaders field optional for team-maintained packages
control: forcemerge 798476 1041464 Hello, On Wed 19 Jul 2023 at 10:18am +01, Luca Boccassi wrote: > Assigning ownership to individuals deters group and team maintenance, > as other team members will feel like they are overstepping when working > on a package for which other people are marked as Uploaders. > > In order to remove all barriers to team contributions and maintenance, > make the 'Uploaders' field optional instead of mandatory when the > 'Maintainer' is a team alias. This allows packages where we do not want > to assign ownership to any individual, but leave them be purely team > maintained, to do so. I wanted to do this some years ago, but the MIA team objected. So you'd need to speak to them first. -- Sean Whitton
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Hello, On Fri 16 Jun 2023 at 05:57PM +01, Luca Boccassi wrote: > Is there anything needed from me to make progress on this? Any changes > required to the last revision posted? Yes, Russ posted some comments on your most recent revision, I believe. -- Sean Whitton signature.asc Description: PGP signature
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Hello, On Tue 13 Jun 2023 at 05:58PM +01, Mark Hindley wrote: > There is a new upstream version of elogind[1] that is already packaged in > Devuan[2] although that uncovered up an upstream issue that I am waiting to be > resolved[3]. So, maybe by the end of this month? > > However, that is only considering whether the packaging and dependencies can > be > made to work (like Simon McVittie, I think they probably can). > > I remain much less convinced that there is a consensus for requiring packages > to > use tmpfiles.d(5) for /var, /tmp and maybe /etc. The recent thread on > debian-devel demonstrated a range of opinion. Thorsten and Bill have just > raised > valid points about chroots. > > So, whilst I am happy to test the dependency changes in elogind, enshrining > this > as a 'should' in the Policy now seems, at least, premature. Cool, thank you. This will simplify resolving this bug. > Reading the proposed text as somebody who is particularly interested > in non-systemd systems, I am struck by the inconsistency between > > Init systems other than ``systemd`` should allow providing the same > functionality as appropriate for each system, for example managing the > directories from the init script shipped by the package. > > and the fact that we no longer expect packages to include init scripts > alongside > their systemd units and even accept their removal, even if other interested > people offer to maintain them and provide tested patches. I'm sympathetic, though, this in itself is not a Policy issue. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, > diff --git a/policy/ap-pkg-alternatives.rst b/policy/ap-pkg-alternatives.rst > index ffa2163..6f7780f 100644 > --- a/policy/ap-pkg-alternatives.rst > +++ b/policy/ap-pkg-alternatives.rst > @@ -24,3 +24,6 @@ See the :manpage:`update-alternatives(8)` man page for > details. > If ``update-alternatives`` does not seem appropriate you may wish to > consider using diversions instead. > > +Do not use alternatives for ``systemd`` configuration files. See > +:doc:`ch-binary` for more information. > + > diff --git a/policy/ap-pkg-diversions.rst b/policy/ap-pkg-diversions.rst > index fe360d1..d299d04 100644 > --- a/policy/ap-pkg-diversions.rst > +++ b/policy/ap-pkg-diversions.rst > @@ -81,3 +81,6 @@ when the file does not exist. > Do not attempt to divert a conffile, as ``dpkg`` does not handle it > well. > > +Do not use diversions for files that have their own native override > mechanisms, > +such as ``systemd`` unit files. See :doc:`ch-binary` for more information. > + > diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst > index e517f26..19635e7 100644 > --- a/policy/ch-binary.rst > +++ b/policy/ch-binary.rst > @@ -371,6 +371,41 @@ against earlier versions of something that previously > did not use > ``update-alternatives``; this is an exception to the usual rule that > versioned conflicts should be avoided.) > > +Diversions are primarily intended as a tool for local administrators or local > +packages to override the behavior of Debian. While there are some > circumstances > +where one Debian package may need to divert a file of another Debian package, > +those circumstances are rare and diversions should only be used as a last > resort > +when no other suitable mechanism exists. Diversion of a file in one Debian > +package by another Debian package should be coordinated between the > maintainers > +of those packages. Maintainers should strongly prefer using other overriding > +mechanisms, instead of diversions, whenever those other mechanisms are > +sufficient to accomplish the same goal. In other words, diversions in > packages > +should be considered a last resort. (When applying the patch I'll probably edit this down to reduce redundancy.) > +One specific case of that rule is that configuration files used by > +``systemd`` components, such as `units, > +<https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description>`_ > +`udev rules, > +<https://www.freedesktop.org/software/systemd/man/udev.html#Rules%20Files>`_ > +`tmpfiles.d, > +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#Configuration%20Directories%20and%20Precedence>`_ > +`modules-load.d, > +<https://www.freedesktop.org/software/systemd/man/modules-load.d.html#Configuration%20Format>`_, > +`sysusers > +<https://www.freedesktop.org/software/systemd/man/sysusers.d.html#Configuration%20Directories%20and%20Precedence>`_ > +and other such files, including those specific to systemd daemons > +(e.g.: `/etc/systemd/system.conf). > +<https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html>`_ > +must not be diverted by any Debian package. Instead, use `masking and > drop-ins > +<https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description>`_. > + > +Alternatives must never be used for ``systemd`` configuration files. The > +alternatives system does not know how to apply changes to services when > updating > +alternatives, so the resulting behavior would be confusing and unpredictable. > +Instead, `aliases > +<https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description>`_ > +can be used to provide alternative implementations of the same named unit. > + > .. _s-maintscriptprompt: > > Prompting in maintainer scripts Seconded. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, On Tue 13 Jun 2023 at 08:45PM +01, Luca Boccassi wrote: > That essentially means it's fine to use diversions and ship releases > using them, so that's exactly what will happen as per Murphy's law. > [...] I don't believe you've made any new arguments in the message to which I'm replying. Based on that, and the other activity this bug has seen, I don't think it would be premature for us to start gathering formal seconds of a version of your patch with my "should strongly prefer" wording substituted for one part of it. Would you like to prepare that patch, or shall one of Russ or I do so? -- Sean Whitton signature.asc Description: PGP signature
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Hello Mark, On Tue 13 Jun 2023 at 01:51PM +01, Mark Hindley wrote: > On Tue, Jun 06, 2023 at 11:58:07AM +0100, Simon McVittie wrote: >> Exactly. My hope is that if we had: >> >> Package: systemd >> Architecture: linux-any >> Provides: default-systemd-tmpfiles, systemd-tmpfiles >> Conflicts: systemd-tmpfiles >> Replaces: systemd-tmpfiles >> >> Package: systemd-standalone-tmpfiles >> Architecture: linux-any >> Provides: systemd-tmpfiles >> Conflicts: systemd-tmpfiles >> Replaces: systemd-tmpfiles >> >> Package: elogind >> Depends: systemd-standalone-tmpfiles# or Recommends? > > In principle and just looking at the dependencies this seems a viable > solution. It is very similar to the way we handle the logind and > default-logind virtual packages. Thank you for reviewing. Do you have a rough idea of how long it would be until you could confirm that this is viable, and implement it in sid? -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, On Tue 06 Jun 2023 at 12:16PM +01, Luca Boccassi wrote: > My understanding is that "should" is effectively optional, ie: it is > not enough to make a package rc-buggy, and while they are generally > followed, there is no actual hard requirement to do so. That is not > enough for me and for this use case. So again my goal here is to make > an hypothetical future dpkg-divert or alternative of a unit file > (wherever it is shipped from) instantly and unambiguously rc-buggy, > with no leeway (again there are no longer any such cases in the > archive as of bookworm, so nothing is affected). If you can suggest an > alternative appropriate wording that can achieve the same effect, that > would be fine to me - I don't mind how it's written, as long as it > meets this requirement. We have more than two bug severities in the BTS and more than two levels of normative language in Policy. It's simply untrue that all but one of each of those is optional. Debian's normative landscape is more complex than that. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, On Tue 06 Jun 2023 at 07:56PM -07, Russ Allbery wrote: > Sean Whitton writes: > >> I think what's a bit peculiar here is using "must" for a case where >> there might be package-specific exceptions. In other cases, Policy uses >> "should" for these cases. Typically "must" rules are simple and >> completely determinate. > > I prefer that too, but in this case, it feels like must is appropriate > for at least systemd configuration files. I've spent some time thinking about this, and I now agree that we should add a "must" for systemd unit files, and the other classes of systemd configuration mentioned in the patch. > And also, just intuitively, I feel like must is correct when people > are using diversions rather than a native mechanism. Diversions add > weird edge cases and we really shouldn't be using them lightly. > > The wording I proposed and that Luca has now adopted therefore uses > must with a caveat. Does that sound okay to you? I still find myself feeling queasy about adding this must-with-caveat. It feels like with the caveat you're trying to get something between "must" and "should", but then rather than build down from "must", why not build up from "should"? I would like to propose: Maintainers should strongly prefer using other overriding mechanisms, instead of diversions, whenever those other mechanisms are sufficient to accomplish the same goal. In other words, diversions in packages should be considered a last resort. I think that this accomplishes everything, in terms of guidance for our maintainers, that the must-with-caveat wording does. But it avoids saying that using diversions over a native mechanism in and of itself renders a package RC-buggy, which doesn't seem right to me. My own experience with diversions is limited, and so I accept that I may well be naively underestimating the badness of the edge cases. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, > diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst > index e517f26..4ceec3f 100644 > --- a/policy/ch-binary.rst > +++ b/policy/ch-binary.rst > + > +Alternatives must never be used for ``systemd`` configuration files. "Must not" rather than "must never" is our standard phrasing, and "must not" is not any normatively weaker than "must never". -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, On Tue 06 Jun 2023 at 11:51AM +01, Luca Boccassi wrote: > Well, the README says: > > "Please submit a bug to the BTS, either with patches attached, or a > reference to a git branch that is publically fetchable." > > The whole project is moving toward git and Salsa, Git, certainly, but not all of us love Salsa. > and it is very annoying to have to do drive-by contributions via > email, it really sucks as a process for contributors, so please > consider re-evaluating this in the future. Patch attached. You are very fast! I just posted another message with some wording review. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, On Mon 05 Jun 2023 at 12:59AM +01, Luca Boccassi wrote: > On Sun, 4 Jun 2023 19:39:49 +0200 Bill Allombert > wrote: >> On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote: >> > If you prefer, I can reword the general rule to be stricter, ie: >> > "packages must not use diversions where native mechanisms are >> > available" or so. Would this be better? >> >> "native mechanisms" seems to vague. > > Well, I originally had written precisely what I meant, but was told on > this thread to "add normative language for only the general case" > instead, so I've done that. That's always going to sound vague. I > cannot do both at the same time. > > As you can see from the latest revision, right now the rule is general > but it's immediately followed by a very concrete and documented > example. Open to precise suggestions on how to improve it. I think what's a bit peculiar here is using "must" for a case where there might be package-specific exceptions. In other cases, Policy uses "should" for these cases. Typically "must" rules are simple and completely determinate. Maintainers do take our "should"s seriously -- let's use that here. It can always be strengthened later. > Diversions and alternatives should be used primarily as a tool for > local administrators and local packages to override the behaviour of > Debian. Its use between Debian packages should be rare, should involve > coordination between the packages and their maintainers, and must only > be used to solve problems that cannot be handled through other > facilities or native mechanisms. In other words, packages in Debian > must not divert a file from another package unless this is arranged > cooperatively between the packages to solve some specific and unusual > problem. How about: Diversions and alternatives are primarily tools for local administrators and local packages to override Debian's default behaviour. Maintainers should prefer to use other, package-specific facilities for overriding configuration, such as systemd's unit file overrides, wherever possible. If diversions and alternatives are to be used, maintainers should co-ordinate with the maintainers of all the packages involved. For example, configuration files used by systemd components should not be diverted with dpkg-divert or the alternatives system without agreement between not only the maintainers of the packages that ship the files, but also the maintainers of the relevant systemd components. I would also like to suggest "their own mechanisms for overriding parts of configuration" over "native overriding mechanisms" in the appendices. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, On Sun 04 Jun 2023 at 01:35PM +01, Luca Boccassi wrote: > In the interest of speeding things up a bit, I've done some rewording > as suggested - moved to the exiting chapter, and use the systemd files > only as an example: > > https://salsa.debian.org/bluca/policy/-/commit/5058bd2f8c742c3d8695e2c98ee3a597d431ffd7 > > Off-topic - any reasons MRs are disabled on the policy repo? It would > be much nicer and quicker to use the Gitlab review process I think, > like we do for other packages. It's actually on-topic -- can you post your proposed patch to this bug for inline review, please? This is documented in README.md. The main reason we have MRs disabled is that we want a complete record of the discussion that led up to a Policy change to be recorded in the BTS. A secondary reason is that I strongly disprefer doing patch review using an interface other than my mail client. -- Sean Whitton signature.asc Description: PGP signature
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Hello, On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote: > So I think the only realistic options for packages that hard-require > this functionality (not all do) are: > > 1. Depends: systemd | systemd-tmpfiles > 2. Depends: systemd-tmpfiles-standalone | systemd-tmpfiles > 3. Depends: default-systemd-tmpfiles | systemd-tmpfiles > > (where the third one is equivalent to one of the first two, depending on > how default-systemd-tmpfiles was implemented), possibly with some more > less-preferred options between the first "|" and the virtual-package > fallback. As you wrote in another message, it's very cheap future-proofing to use a virtual package for whichever actual solution we're implementing, so I think we should do that. > Another possible mitigation which I haven't previously seen proposed > is giving *elogind* a Depends or Recommends on systemd-*-standalone. > I think that would work to mitigate the failure mode with (1.) and (B.), > and the installed-size argument seems less interesting here because the > sort of systems that require elogind are already much larger anyway. > Would the elogind maintainers be willing to consider this? Does anyone > see a reason why it wouldn't work? So to confirm, you think that if the elogind maintainers did this, then default-systemd-tmpfiles could point at systemd rather than systemd-standalone-tmpfiles, which the systemd maintainers prefer, but in addition, there aren't any scenarios in which people's systems are likely to be re-arranged when they don't want them to be? > As a maintainer of system services, I would not be at all happy with > expecting the maintainer of every system service that requires tmpfiles > to have this conversation again and again. Obviously as a technical > committee member and occasional Policy contributor, I've chosen to take > on some of the burden of decisions like this one; but when I'm working > on dbus or polkitd or even openarena-server, I should be able to follow > a project decision, and be reasonably confident that I won't get angry > RC bug reports about it (and if I do, I should be able to refer the bug > reporter to a project decision instead of having to re-litigate it). > Putting this sort of thing on individual package maintainers seems like > a recipe for making it no longer fun to maintain a package. Yes, let's figure out a standard solution and write it in Policy. The reasoning may well be applicable to similar things in the future. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello Luca, On Mon 08 May 2023 at 08:07PM +01, Luca Boccassi wrote: > The specific difference, for which I think an explicit call out is > needed, is because these config files are shipped by some packages but > are not used _by_ them, they are consumed by systemd (or udev, or > kmod, etc). Specifically, if package A ships a.service, and package B > overrides it, even if the maintainers of A and B agree, that's still > not good enough for me, as they are really affecting systemd, which is > the consumer and the provider of the interface they are using, and > ultimately the first port of call for bug reports. This is especially > true for udev. > > So in my latest revision of the patch, the general rule is as > requested by Russ and as you mention it, but there is an explicit, > stricter rule to cover this case, which is important to me. Policy > calls out core component software in many places, such as dpkg, and > systemd is already mentioned in other parts of the policy, so it did > not seem too far-fetched to me. I'm afraid I'm not convinced. I'd second a patch where systemd is used as an example of the rule, as I suggested. Thank you for the additional commit regarding kmod. It is good to have been made aware of issue, but let's discuss it in a separate bug after making this change -- the considerations might be quite different. On Tue 09 May 2023 at 12:31AM +01, Luca Boccassi wrote: > On Mon, 08 May 2023 14:14:30 -0700 Russ Allbery wrote: > >> Oh, thank you! I had completely forgotten that we said something >> about this under maintainer scripts. >> >> That doesn't entirely cover this case (because systemd and udev may >> not be "that package" in this sense), but it covers much of the >> general case. > > Would you like me to reword/move the new snippet? Yes, thank you. I will review the new version. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, On Mon 08 May 2023 at 12:52PM -07, Russ Allbery wrote: > Sean Whitton writes: >> On Mon 08 May 2023 at 08:48AM -07, Russ Allbery wrote: > >>> In other words, dpkg-divert is primarily for local administrators, >>> non-Policy-compliant local packages that are doing unusual things, and >>> the occasional rare problem that requires special coordination between >>> packages, not something that Debian packages should be doing to other >>> packages without explicit coordination. > >>> The rule about systemd and udev files doesn't entirely fall out of that >>> statement, > >> Hmm, could you explain why? > > It didn't fall out of the above statement because the systemd unit file > may not be shipped with the systemd package, but by some other random > package, so you could have an explicit coordination with the package that > provides the unit file but still be doing something that the systemd > maintainers don't want to support. > > I think it does fall out of the somewhat squishier statement that you > shouldn't use diversions when there's some other available mechanism to > accomplish the same goal. Thanks, I see. I agree that we should have the latter statement. >> I don't mean to dismiss the significant impact on the systemd >> maintainers that's being claimed, but specifically calling out udev and >> systemd configuration files seems strangely specific, for Policy, to me. > > I think they're a special case of the general rule that if there's some > mechanism other than diversions to do what you want, you should use it > instead, but it's such a common special case that we should call it out > explicitly, particularly since a lot of people right now don't seem to > know about masking or drop-ins. So in other words, I think I basically > agree with this, but I think it's worth spending some words on systemd and > udev, more as a communication strategy than anything else. Okay cool, I'm glad you're happy with my "For example ..." thing. -- Sean Whitton signature.asc Description: PGP signature
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Hello, On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote: > I've done an initial attempt to define the wording, although I'm sure > it will need quite a few changes. Attached as a patch, and also > available on Salsa: > > https://salsa.debian.org/bluca/policy/-/commits/tmpfiles > > Happy to move/reword/change/enhance as required. Thanks. > For now I've kept only a mention of the 'systemd-tmpfiles' virtual > package. As maintainers we would really prefer if the 'main' > implementation is pulled in whenever possible. When a minimal > installation is desired (ie, a minbase), it is possible to manually > specify the -standalone variant. > > This was a controversial point last year, see: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017441 Hmm. I don't have personal experience with this sort of thing, but based on some of the examples in that bug, it seems like doing this could cause apt to change people's systems around in ways they strongly disprefer. What you propose seems like it could cause unpleasant surprises. > We could even decide that no dependency is added at all by dh, and > instead the build tool needs to decide if it's building an image where > tmpfiles snippets need to be ran, and if so pull in the preferred > alternative. This is a highly inspecific response, but: aren't things expressed by dependencies generally less work for everyone than more special cases to be handled by each build tool? -- Sean Whitton signature.asc Description: PGP signature
Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Hello, On Mon 08 May 2023 at 08:48AM -07, Russ Allbery wrote: > In other words, dpkg-divert is primarily for local administrators, > non-Policy-compliant local packages that are doing unusual things, and the > occasional rare problem that requires special coordination between > packages, not something that Debian packages should be doing to other > packages without explicit coordination. > > The rule about systemd and udev files doesn't entirely fall out of that > statement, Hmm, could you explain why? > so we can still include a specific statement about them, noting that > drop-ins and masking make dpkg-divert unnecessary (and those > facilities produce better tool behavior) and therefore it should not > be used. > > So, ideally, the way I'd prefer to move forward is for us to add a new > section to the main Policy manual on diversions (probably 10.11), document > that this is primarily a tool for local administrators and local packages > to override the behavior of Debian, and that its use between Debian > packages should be rare, should involve coordination between the packages, > and should only be used to solve problems that cannot be handled through > other facilities such as alternatives or package-specific tools like > systemd's support for drop-ins and masking. And then explicitly call out > systemd and udev configuration as cases where dpkg-divert should not be > used, alongside conffiles and critical system files. I don't mean to dismiss the significant impact on the systemd maintainers that's being claimed, but specifically calling out udev and systemd configuration files seems strangely specific, for Policy, to me. The general prohibition seems justified, and then I would be inclined to use the systemd and udev configuration files case as an example, which explains and justifies the existence of the rule. So instead of [don't use dpkg-divert on other packages's files] In particular, packages should not divert systemd and udev configuration files. Doing so leads to confusing command output. it seems more natural to me to do something like [don't use dpkg-divert on other packages's files] For example, diverting another package's systemd units or udev configuration files can result in confusing command output. If this was a mistake that maintainers seemed to habitually make, the former would make sense, but so far I think we have just one or a few concrete examples, and so the correct thing to do seems to me to be to add normative language for only the general case. -- Sean Whitton signature.asc Description: PGP signature
Re: nocheck (don't run) vs nodoc (don't build)
Hello, On Wed 26 Apr 2023 at 04:48PM -06, Sam Hartman wrote: > I guess that's consistent with RFC 2119. > And RFC 2119 SHOULD means that the requirement is RECOMMENDED, and an > implementation that does not follow the SHOULD needs to have a reason > for not following the recommendation. Just to note that Debian Policy's definition of these terms is not quite the same as the RFC process definitions (I know you know this -- just wanted to note that they're not the most relevant definitions). -- Sean Whitton signature.asc Description: PGP signature
Re: Bug #1013195: base-files: Please add AGPL-3 license
Hello, On Wed 26 Apr 2023 at 11:53AM -07, Russ Allbery wrote: > Robert Ernst writes: > >> Also I kindly remark my still open questions regarding: > >> - Is there enough manpower in the debian policy team? > > No, not really. I think that we have enough editorial manpower. It's relatively rare for things to be left hanging once consensus is established. We would definitely benefit from more people working on patch text, engaging in discussions to establish consensus etc. > I had at one point planned out next steps for resolving all the requests > to add new licenses to base-files. The root problem is that it's not > clear what the rest of the project expects in terms of license inclusion > in base-files, and we need to pin that down so that we have a somewhat > objective criteria. That should likely be a debian-devel conversation > that's actively guided to reach some sort of consensus, and I suspect some > sort of straw polling would be useful since there are a lot of opinions > and it's the sort of topic where we may not be able to judge the consensus > of the project purely from the discussion. > > Things that I think need to be resolved: > > [...] Thank you for these thoughts. I agree with you about what needs to be done. -- Sean Whitton signature.asc Description: PGP signature
Re: Reducing allowed Vcs for packaging?
Hello,
On Sun 26 Feb 2023 at 02:24PM +01, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of
> them for
> one package. No package makes use of several Vcs references and frankly I do
> not
> see why this was supported in the first place.
>
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
>
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.
>
> I would like to suggest removing the possibility to specify several systems
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in
> debian/control
> should be adapted to do the specified thing.
>
> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
Why don't we just fix all those packacges, instead of changing any
documents? Is there anyone who actually wants to introduce new packages
not using git? I'm not so sure.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
Hello, On Mon 20 Feb 2023 at 01:59PM GMT, Jelmer Vernooij wrote: > 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? Thanks for filing the patch. As to your question, it's the latter (I'm not sure whether or not the former is true, but in any case, Policy contains recommendations in addition to musts and shoulds). -- Sean Whitton signature.asc Description: PGP signature
Re: small typo in policy/ap-pkg-diversions.rst line 53
Hello, On Thu 16 Feb 2023 at 05:09PM +01, Max-Julian Pogner wrote: > Hallo, > > as requested, i filed the bug report. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031403 > > a patch is attached. > > because of the large number of existing bugs against the 'debian-policy' > package, i am not 100% sure a similar bug did not already exist. However, i > could not find any existing similar bug. No problem, thank you for checking! -- Sean Whitton signature.asc Description: PGP signature
Re: small typo in policy/ap-pkg-diversions.rst line 53
Hello, On Wed 15 Feb 2023 at 01:46PM +01, Max-Julian Pogner wrote: > there's a small typo in file policy/ap-pkg-diversions.rst list 53 > (salsa link: > https://salsa.debian.org/dbnpolicy/policy/-/blob/3cfbd29f3d412894b275fbb98624d3e7d8f9dd4c/policy/ap-pkg-diversions.rst?plain=1#L53 > ) > > The line currently reads > >> if [ remove = "$1" -o abort-install = "$1" -o disappear = "$1 ]; then > > which contains a shell syntax error, but it should instead read: > >> if [ remove = "$1" -o abort-install = "$1" -o disappear = "$1" ]; then > > note the difference in quoting (one double quote added). Thanks, but could you file this as a bug? -- Sean Whitton signature.asc Description: PGP signature
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
Hello, On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote: > 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) This strikes me as a matter for devref not Policy? -- Sean Whitton
Re: Request to contribute translation (zh, Chinese中文)
Hello, On Fri 27 Jan 2023 at 09:40AM -08, Russ Allbery wrote: > "M. Zhou" writes: > >> I was the former zh_CN translator for apt and dpkg. And I had the >> exactly the same idea for translating other documents for Debian many >> years ago. If I remembered what I have been told correctly, debian >> policy is an very important document and is frequently updated. We have >> to make sure the content can be consistently conveyed without any >> discrepancy introduced by translation. Meanwhile, an out-of-sync >> translated version of debian policy would also be a headache to the >> policy team once made official. > > I think this should be okay now. Policy uses the normal translation > framework, so if a part of it has been updated and the translation is out > of date, I believe that section will revert to English (if I understand > how the translation machinery works). > > That said, we haven't tried to incorporate translation work in a while, so > some of the machinery has probably rusted and will need repairs. Yup, please create MRs with translations here: <https://salsa.debian.org/dbnpolicy/policy-l10n-merge-requests-here> -- Sean Whitton
Bug#1020248: marked as done (debian-policy: Clarifying nomenclature for control file names)
Hello, On Sat 17 Dec 2022 at 04:43PM +01, Guillem Jover wrote: > Control: reopen -1 > > Hi! > > Sorry, probably my fault! As I tend to use «Fixes:» git pseudo-fields > for things that fix part of a bug, but are not intended yet to close it, > for which I use «Closes:». > > And for some reason I think I also got the impression, even though > the stanza changes had been committed, they could still be backed out. > (BTW I've now gone over the wiki and updated all paragraph references > that applied to stanza.) > > In any case, I've sat down and gone over the meat of the original > report. See below. We're sticking with 'stanza', and in light of that, could you confirm that the bug is reopened in order to make additional fixes, rather than back anything else out? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: new policy upload before the freeze?
Hello, On Thu 15 Dec 2022 at 08:44AM -08, Russ Allbery wrote: > Holger Levsen writes: > >> do you plan to release a new version of debian-policy before the freeze >> in January? > >> I'm wondering whether I should start polishing uploads now or better >> wait. > > I personally have vacation upcoming and am *tentatively* planning to use > some of that for Policy work, but am unlikely to be able to really get > started until after Christmas. I can aim for uploading the current next > branch sometime during that week. > > I have no objections to uploading it before then; I just probably won't > have time personally. Thanks Holger for pointing this out. I'll cut a release today or tomorrow. -- Sean Whitton
Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
Hello, On Sun 02 Oct 2022 at 09:03PM +02, Niels Thykier wrote: > Here is my view in short: As I see it, only the values `no` and > `binary-targets` for `Rules-Requires-Root` makes sense for the *policy defined > targets*[1] at the moment. Accordingly, Debian policy can probably reduce the > field to only cover `binary-targets` and `no` (and describe the remaining > values as "[they] will mostly behave like `no`, but read more in the dpkg > documentation for concrete the non-policy relevant use-case") > > In theory, you could use `Rules-Requires-Root` to cover the static ownership > cases (where you need to chown files and store that ownership in the deb). > However, that would require people to consistently use fakeroot with -l + -s > (which, to my knowledge, no one does) - failure to do so would just silently > loose the ownership and the files would end up with the wrong owner. > > On a related note, both Guillem and I agreed a while back that ownership > (among other) should ideally be specifiably without using chown. While a > concrete method has not yet materialized, I am not working on supporting > static ownership via chown in debhelper (nor do I plan to do so), so in > practice `binary-targets` is the only reliable way to setup static ownership > for any package built via debhelper[2]. > > So in summary, with the current tooling, only `no` and `binary-targets` make > sense for *policy defined targets* and I am not aware of anything that would > change that. Many thanks for the input. Could you just confirm that there isn't any info in Policy which isn't also in dpkg documentation? If so, then if someone particularly wants to see this gone from the manual they can prepare a patch for seconding. > PS: As for the adding a recommendation to use `Rules-Requires-Root: no` where > possible. I would second such as change. Over half of all Debian source > packages in testing have the value, and adoption has been quite fast despite > very little push from Guillem and I on it. For me, the recommendation would > be documenting public sentiment on this topic. > > Source: https://trends.debian.net/rulesreqroot_testing-percent.png Cool. I think that would be fine too. -- Sean Whitton signature.asc Description: PGP signature
Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads
Hello, On Tue 20 Sep 2022 at 09:21PM -07, Russ Allbery wrote: > In .changes files for source-only uploads, the Binary and > Description fields are not present. Document this, and be clearer > in the description of the Description field for .changes files that > only descriptions of binary packages are included. > --- > policy/ch-controlfields.rst | 20 +++- > 1 file changed, 11 insertions(+), 9 deletions(-) > > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 428b8a7..f85f75d 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -278,7 +278,7 @@ The fields in this file are: > > - :ref:`Source ` (mandatory) > > -- :ref:`Binary ` (mandatory) > +- :ref:`Binary ` > > - :ref:`Architecture ` (mandatory) > > @@ -292,7 +292,7 @@ The fields in this file are: > > - :ref:`Changed-By ` > > -- :ref:`Description ` (mandatory) > +- :ref:`Description ` > > - :ref:`Closes ` > > @@ -809,12 +809,13 @@ See :ref:`s-descriptions` for further information on > this. > > In a ``.changes`` file, the ``Description`` field contains a summary of > -the descriptions for the packages being uploaded. For this case, the > -first line of the field value (the part on the same line as > -``Description:``) is always empty. It is a multiline field, with one > -line per package. Each line is indented by one space and contains the > -name of a binary package, a space, a hyphen (``-``), a space, and the > -short description line from that package. > +the descriptions of the binary packages being uploaded. (``.changes`` > +files for uploads containing only source packages will not have this > +field.) For this case, the first line of the field value (the part on the > +same line as ``Description:``) is always empty. It is a multiline field, > +with one line per binary package. Each line is indented by one space and > +contains the name of a binary package, a space, a hyphen (``-``), a space, > +and the short description line from that package. > > .. _s-f-Distribution: > > @@ -924,7 +925,8 @@ every architecture. The source control file doesn't > contain details of > which architectures are appropriate for which of the binary packages. > > When it appears in a ``.changes`` file, it lists the names of the binary > -packages being uploaded, separated by whitespace (not commas). > +packages being uploaded, separated by whitespace (not commas). If only > +source packages are being uploaded, this field will not be present. > > .. _s-f-Installed-Size: Seconded. -- Sean Whitton signature.asc Description: PGP signature
Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5
Hello, On Tue 20 Sep 2022 at 06:52PM -07, Russ Allbery wrote: > > Starting with dpkg 1.18.5, several maintainer script actions > involving a new package version get that version as an argument > after the old version. Update Policy's maintainer script > documentation accordingly. > --- > policy/ch-maintainerscripts.rst | 32 > 1 file changed, 16 insertions(+), 16 deletions(-) > > diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst > index 709aabf..724074c 100644 > --- a/policy/ch-maintainerscripts.rst > +++ b/policy/ch-maintainerscripts.rst > @@ -107,8 +107,8 @@ old version of a package that is being upgraded from or > downgraded from. > The ``preinst`` script may be called in the following ways: > > | ``new-preinst`` install > -| ``new-preinst`` install *old-version* > -| ``new-preinst`` upgrade *old-version* > +| ``new-preinst`` install *old-version* *new-version* > +| ``new-preinst`` upgrade *old-version* *new-version* > > The package will not yet be unpacked, so the ``preinst`` script > cannot rely on any files included in its package. Only essential > @@ -168,10 +168,10 @@ The ``prerm`` script may be called in the following > ways: > where dependencies are only "Half-Installed" due to a partial > upgrade. > > -``new-prerm`` failed-upgrade *old-version* > -Called during error handling when ``prerm upgrade`` fails. The new > package will not yet be > -unpacked, and all the same constraints as for ``preinst upgrade`` > -apply. > +``new-prerm`` failed-upgrade *old-version* *new-version* > +Called during error handling when ``prerm upgrade`` fails. The new > +package will not yet be unpacked, and all the same constraints as for > +``preinst upgrade`` apply. > > The ``postrm`` script may be called in the following ways: > > @@ -189,7 +189,7 @@ The ``postrm`` script may be called in the following ways: > the package's dependencies if those dependencies are unavailable. > [#]_ > > -``new-postrm`` failed-upgrade *old-version* > +``new-postrm`` failed-upgrade *old-version* *new-version* > Called when the old ``postrm upgrade`` action fails. The new package > will be unpacked, but only essential packages and pre-dependencies > can be relied on. Pre-dependencies will either be configured or will > @@ -197,8 +197,8 @@ The ``postrm`` script may be called in the following ways: > configured and was never removed. > > | ``new-postrm`` abort-install > -| ``new-postrm`` abort-install *old-version* > -| ``new-postrm`` abort-upgrade *old-version* > +| ``new-postrm`` abort-install *old-version* *new-version* > +| ``new-postrm`` abort-upgrade *old-version* *new-version* > > Called before unpacking the new package as part of the error > handling of ``preinst`` failures. May assume the same state as > @@ -229,7 +229,7 @@ These are the "error unwind" calls listed below. > > .. parsed-literal:: > > - new-prerm failed-upgrade *old-version* > + new-prerm failed-upgrade *old-version* *new-version* > > If this works, the upgrade continues. If this does not work, the > error unwind: > @@ -305,13 +305,13 @@ These are the "error unwind" calls listed below. > > .. parsed-literal:: > > - *new-preinst* upgrade *old-version* > + *new-preinst* upgrade *old-version* *new-version* > > If this fails, we call: > > .. parsed-literal:: > > - *new-postrm* abort-upgrade *old-version* > + *new-postrm* abort-upgrade *old-version* *new-version* > > i. If that works, then > > @@ -331,13 +331,13 @@ These are the "error unwind" calls listed below. > > .. parsed-literal:: > > - *new-preinst* install *old-version* > + *new-preinst* install *old-version* *new-version* > > Error unwind: > > .. parsed-literal:: > > - *new-postrm* abort-install *old-version* > + *new-postrm* abort-install *old-version* *new-version* > > If this fails, the package is left in a "Half-Installed" state, > which requires a reinstall. If it works, the packages is left in > @@ -397,7 +397,7 @@ These are the "error unwind" calls listed below. > > .. parsed-literal:: > > - *new-postrm* failed-upgrade *old-version* > + *new-postrm* failed-upgrade *old-version* *new-version* > > If this works, installation continues. If not, Error unwind: > > @@ -410,7 +410,7 @@ These are the "error unwind" calls listed below. > > .. parsed-literal:: > > - *new-postrm* abort-upgrade *old-version* > + *new-postrm* abort-upgrade *old-version* *new-version* > > If this fails, the old version is left in a "Half-Installed" > state. If it works, dpkg now calls: Seconded. -- Sean Whitton signature.asc Description: PGP signature
Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages
control: tag -1 + pending Hello, On Tue 20 Sep 2022 at 06:39PM -07, Russ Allbery wrote: > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 428b8a7..ea8f4a3 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -540,6 +540,9 @@ Thus only the first three components of the policy > version are > significant in the *Standards-Version* control field, and so either > these three components or all four components may be specified. [#]_ > > +udebs and source packages that only produce udebs do not use > +``Standards-Version``. > + > .. _s-f-Version: > > ``Version`` > diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst > index 289c9a9..a279c26 100644 > --- a/policy/ch-scope.rst > +++ b/policy/ch-scope.rst > @@ -71,11 +71,11 @@ Much of the information presented in this manual will be > useful even > when building a package which is to be distributed in some other way or > is intended for local use only. > > -udebs (stripped-down binary packages used by the Debian Installer) do > -not comply with all of the requirements discussed here. See the `Debian > -Installer internals > -manual <https://d-i.debian.org/doc/internals/ch03.html>`_ for > -more information about them. > +udebs (stripped-down binary packages used by the Debian Installer) and > +source packages that produce only udebs do not comply with all of the > +requirements discussed here. See the `Debian Installer internals manual > +<https://d-i.debian.org/doc/internals/ch03.html>`_ for more information > +about them. > > .. [#] > Informally, the criteria used for inclusion is that the material meet Seconded and applied, thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph
Hello Charles, On Thu 22 Sep 2022 at 02:26PM +09, Charles Plessy wrote: > So point taken about "paragraph", although interestingly, the > Simple English definition of "paragraph" is quite spot on if one would > replace "sentence" with "field": ”one or more sentences that are written > together with no line breaks separating them. I think that the quoted definition rather argues against 'paragraph' -- it makes it clear that being made up of sentences, and not non-sentences, is essential to paragraph-hood. In other words, it only becomes spot on if you change the core meaning into a definition of something else. > I understand about avoiding ambiguity, but in my opinion it is the price > to pay to be able to translate information into simple words from > English to non-European languages. Although the Policy itself is not > going to be translated, I think that it can be advantageous if its > contents can be discussed in simple words in people's native languages. It may yet be translated! We have the po4a setup :) -- Sean Whitton
Re: Idea for Policy expert reviewer list
Hello, On Tue 20 Sep 2022 at 09:39AM -07, Russ Allbery wrote: > What do people think? Helpful innovation, or just extra bookkeeping that > isn't worth the effort? If people do think this is a good idea, I'll > bring it up on debian-devel for further discussion (and then, if we > adopted it, it would be a debian-devel-announce post). I think this is a nice idea, and could help a lot with our bugs. I think that we should do it in the lightest-weight way that we can. That is, let's 1) have the list 2) write down in the README that we'll CC people at the point that things have got sufficiently concrete, as you say 3) announce on d-d-a that we would like people to put themselves on the list / ask us to put them on the list. Seems to me this could achieve everything you want to achieve without introducing any serious bookkeeping work for anyone. (Additionally, not sure why this would need to go to debian-devel -- seems like a Policy team-internal thing.) -- Sean Whitton signature.asc Description: PGP signature
Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages
Hello, On Mon 19 Sep 2022 at 09:29PM -07, Russ Allbery wrote: > So, in addition to saying that Standards-Version is generally not used for > udebs or for source packages that only build udebs (I would use wording > like that rather than "required" since Policy puts no requirements on > udebs at all), maybe we should add to this paragraph in 1.1 (Scopes): > > udebs (stripped-down binary packages used by the Debian Installer) do > not comply with all of the requirements discussed here. See the Debian > Installer internals manual for more information about them. > > That could be as simple as saying "udebs (...) and source packages that > produce only udebs do not comply" Sounds good to me. -- Sean Whitton signature.asc Description: PGP signature
Bug#975631: debian-policy: window manager: remove reference to Debian menu
control: tag -1 + pending Hello, On Sun 18 Sep 2022 at 07:53PM -07, Russ Allbery wrote: > Ansgar writes: > >> Section 11.8.4 "Packages providing a window manager" still references >> the Debian menu. But the Debian menu is deprecated. > >> I suggest to remove the reference, for example with the patch below. > >> --- a/policy/ch-customized-programs.rst >> +++ b/policy/ch-customized-programs.rst >> @@ -345,13 +345,7 @@ Packages that provide a window manager should declare >> in their >> alternative for ``/usr/bin/x-window-manager``, with a priority >> calculated as follows: >> >> -- Start with a priority of 20. >> - >> -- If the window manager supports the Debian menu system, add 20 points >> - if this support is available in the package's default configuration >> - (i.e., no configuration files belonging to the system or user have to >> - be edited to activate the feature); if configuration files must be >> - modified, add only 10 points. >> +- Start with a priority of 40. >> >> - If the window manager complies with `The Window Manager Specification >> Project <https://www.freedesktop.org/wiki/Specifications/wm-spec>`_, > > Yes, this looks right to me. Seconded. Likewise seconded, and applied. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020248: debian-policy: Clarifying nomenclature for control file names
Hello, On Sun 18 Sep 2022 at 05:34PM -07, Russ Allbery wrote: > Sean Whitton writes: >> On Mon 19 Sep 2022 at 12:45AM +02, Guillem Jover wrote: > >>> So, personally, I'd be happy to fully switch to stanza TBH, because it >>> seems more specific to our use, probably easier to search for, and >>> it's shorter. > >> I think this is fine for Policy to do. > > I vote for switching to stanza. Paragraph is going to be confusing when > talking about package descriptions, which often have multiple paragraphs > in the normal English meaning of the term. Yes, I had this example in mind too. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020248: debian-policy: Clarifying nomenclature for control file names
Hello, On Mon 19 Sep 2022 at 12:45AM +02, Guillem Jover wrote: > I went for paragraph, because dpkg has some instances of it already in > docs and code (and stanza only in code), and mainly because the Debian > policy uses almost exclusively paragraph for this with a single > mention of "stanza" in a footnote to mention it's a common alias or > similar. Hmm, I see. > So, personally, I'd be happy to fully switch to stanza TBH, because it > seems more specific to our use, probably easier to search for, and > it's shorter. I think this is fine for Policy to do. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020248: debian-policy: Clarifying nomenclature for control file names
Hello, On Sun 18 Sep 2022 at 10:28PM +02, Guillem Jover wrote: > So, how does «source package paragraph» and «binary package paragraph» > (of the «template control file») sound instead? Can we standardise on 'stanza', please? I thought that was already standard, and "paragraph" is for prose. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Native source package format with non-native version
With three first preference votes for A and five first preference votes for C, the outcome is no longer in doubt. Therefore, using its powers under constitution 6.1.5, the Technical Committee issues the following advice: 1. It is not a bug of any severity for a package with a non-native version number to use a native source package format. 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise complain, when a non-native version number is used w/ 3.0 (native). 3. We suggest that the wontfix tag on #737634 be reconsidered. 4. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. However, we recommend discontinuing use of 1.0-with-diff in other circumstances, to simplify the contents of the archive. This is because there is currently no other source format which is such that avoid both (i) uploading the whole source, including upstream, for every upload; and (ii) having to maintain debian/patches/ inside the package tree. 5. We decline to comment on the recent source package format MBF. -- Sean Whitton
Bug#1008480: debian-policy: The mime-support package was split into media-types and mailcap
control: tag -1 + pending Hello, On Sun 27 Mar 2022 at 12:47PM +09, Charles Plessy wrote: > Package: debian-policy > Version: 4.6.0.1 > Severity: normal > X-Debbugs-Cc: ple...@debian.org > > Hi Russ and Sean, > > it is a long time I have not posted here! > > In the previous release cycle, I have split the mime-support into the > media-types and the mailcap packages. > > The patch below updates the Policy to reflect that. This is technically a normative change but since the change has already been made in the archive, I've just gone ahead and applied it to 'next'. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Bug#1006912: is it time to have account deletion in policy?
Hello, On Sat 12 Mar 2022 at 03:01PM +01, Marc Haber wrote: > On Sat, Mar 12, 2022 at 01:00:44PM +, Holger Levsen wrote: >> Roland Clobus has put a lot of work & thoughts into reproducible images, so >> I've >> added him to cc: now, so he can comment on this aspect of #1006912. > > Policy editors, I think we can now choose between taking care of the > needs of reproducible images right with this policy change or do > de-scope this temporarily until we have settled on the new wording > (which also includes some definitions) and then handle this in a second > change. I think the second change also needs the base-passwd people in > the loop. The latter, please, assuming I'm not misunderstanding and the first change makes things worse on the reproducibility front. -- Sean Whitton signature.asc Description: PGP signature
Bug#1006912: is it time to have account deletion in policy?
Hello Marc, On Tue 08 Mar 2022 at 07:40am +01, Marc Haber wrote: > How about putting advice like this in policy: > > Suggestion 1: > Create a dedicated chapter (which would ideally be placed between the > current chapters 9.2.1. Introduction and 9.2.2. UID and GID classes) > named "dynamically allocated system users or groups for packages" with > the following contents: > - packages can create users and groups on installation > - usernames should be chosen wisely, allowing to deduce the related > package from the name, and prefixed with an underscore This sounds good, though we would need an extremely strong argument for inserting rather than appending the new section -- we do not want to renumber sections not just because it breaks hyperlinks, but because it breaks purely textual references to Policy sections in bugs that remain open, mailing list posts to which people still refer, etc. > - adduser --system is the preferred method to create package account, it > takes responsibility of being policy compliant. Other packages doing > this job might exist (dh-sysuser, for example). It would be good to get some input from people who use other methods. I would always look to adduser myself, but there might be others who feel strongly that it's not right for certain classes of case -- perhaps we want to limit the scope of this advice a bit. > Suggestion 2a: > Document that a package should not delete its user on uninstallation > and/or purge. This reflects current practice of most packages but might > need changes in some packages that currently delete their user. Those > packages are the reason that this policy item should not be introduced > as a MUST. Sounds good. > Suggestion 2b: > Document that a package may lock its user on uninstall, but leave it on > the system on purge. That way, a leftover account could not be used as > an attack vector and just blocks the uid/gid and the name. On > reinstallation of a package, the existing, locked account would just be > unlocked. > > This would be a new behavior that could be worth documenting in Policy. > Should the policy editors indicate that this might be an option, adduser > would be willing to implement a deluser --lock --system option that > would lock a named account if its uid is in the appropriate range for > system accounts, and adduser --system would not error out if the account > already exists and would just remove the lock. Thus implementing this > option in a package would just mean to add the appropriat deluser call > to postrm uninstall while postinst can remain unchanged. Sounds like a nice improvement on the current situation. > I am willing to suggest wording, but I am not a policy expert and > wording would probably be better if an experienced policy editor would > write the appropriate language. How would a new chapter be inserted in > Policy without destroying existing references to chapter numbers? Please go ahead and write a patch. The Policy Editors are happy to review and edit proposed wording but we can't be responsible for producing all of the text that gets added to Policy. -- Sean Whitton
Bug#1004522: debian-policy: Proposing new virtual packages: wayland-session, x-session
Hello Simon, On Sun 30 Jan 2022 at 02:18pm GMT, Simon McVittie wrote: > On Sat, 29 Jan 2022 at 20:12:21 +, Simon McVittie wrote: >> I propose this entry for virtual-package-names-list.yaml: >> >> - name: wayland-session >> description: a Wayland desktop session >> (/usr/share/wayland-sessions/*.desktop) > > Having looked more closely at display managers, I think we should also > consider adding: > > - name: x-session > description: an X11 desktop session registered via > /usr/share/xsessions/*.desktop Some time has passed without objections so I would be happy to add these two virtual packages. My only concern is that there are going to be quite a few virtual packages in this area, now, and the virtual packages list will contain only terse descriptions of each one. Someone packaging a new session/display manager/WM might have a hard time figuring out what to use, unless they happen to stumble across the discussion in this bug. What do you think about adding a condensed version of your reasoning to the Policy Manual somewhere? -- Sean Whitton
Bug#1004522: debian-policy: Proposing new virtual package: wayland-session
Hello,
On Sat 29 Jan 2022 at 08:12PM GMT, Simon McVittie wrote:
> Package: debian-policy
> Version: 4.6.0.1
> Severity: wishlist
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> GNOME's gdm3 and KDE's sddm both enumerate possible Wayland sessions in
> /usr/{,local/}share/wayland-sessions/*.desktop and make them available
> as desktop sessions that users can choose, in addition to listing the
> X11 sessions that they traditionally did.
>
> At the moment, installing gdm3 pulls in either gnome-session (a minimal
> GNOME desktop), or some sort of X11 thing (usually a session manager,
> but sometimes a window manager or an xterm), but it should ideally
> be possible to install gdm3 as a login prompt from which to launch a
> non-GNOME Wayland session like weston or sway.
>
> I propose this entry for virtual-package-names-list.yaml:
>
> - name: wayland-session
> description: a Wayland desktop session
> (/usr/share/wayland-sessions/*.desktop)
>
> According to `apt-file search`, it should initially be provided by these:
>
> gnome-session: /usr/share/wayland-sessions/gnome.desktop
> phosh: /usr/share/wayland-sessions/phosh.desktop
> plasma-workspace-wayland: /usr/share/wayland-sessions/plasmawayland.desktop
> sway: /usr/share/wayland-sessions/sway.desktop
> weston: /usr/share/wayland-sessions/weston.desktop
>
> and perhaps also (I don't know how practical this one is for actual use):
>
> mir-demos: /usr/share/wayland-sessions/mir-shell.desktop
Seems fine. Just to confirm, the primary use case is so that if a
package providing wayland-session is installed, a display manager like
gdm3 won't try to install GNOME?
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus
control: tag -1 + pending
Hello,
On Sat 29 Jan 2022 at 08:24PM GMT, Simon McVittie wrote:
> On Thu, 23 Dec 2021 at 21:26:53 -0700, Sean Whitton wrote:
>> On Fri 29 Oct 2021 at 11:12AM +01, Simon McVittie wrote:
>> > it seems like a good time to introduce {default-,}dbus-system-bus
>> > virtual packages, mirroring {default-,}dbus-session-bus.
>>
>> virtual-package-names-list.yaml says that proposed new virtual package
>> names are meant to be sent to d-devel, not just filed as a bug against
>> debian-policy, so perhaps you could do that and we'll give it a week,
>> then I'll go ahead and add these?
>
> I sent this to -devel in December. There were no objections, and one
> positive reply.
I've committed it to the 'next' branch.
It looks like seconds were counted for recent virtual package additions,
but the documented procedure is lighter weight, so I've just gone ahead
and committed. It seems appropriate not to require seconding for these.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition
Hello Joe, Thanks for the patch. Here's a review: On Sat 13 Nov 2021 at 11:21PM -05, Joe Nahmias wrote: > + > + Pre-compiled executable binary or other non human-editable > files; > + The reason we remove these is also DFSG. > + > + > + > + Files intended for use with other platforms. > + We don't remove files for the sole reason that they're intended for use on other platforms. It's typically only done if the files are huge. So please remove this one from the list. How about just saying: we always remove non-DFSG files if the package is intended for main or contrib, and sometimes there are other files that are removed for technical reasons or because they are both unneeded and very large, and both these sorts of removal are documented using this field? > + > +These types of files, or any others that Debian does not want to > +include in our archive, must be stripped from the upstream tarball > +prior to uploading. The Files-Excluded field > serves How about "are stripped" not "must be stripped", as the normative stuff is explained more precisely over in the Policy manual itself? > +to document the removal of these files from the original upstream > +source. This allows others to understand or audit how the source > +distribution in Debian is derived from the upstream source. > + > + > +Additionally, once documented in this manner, various tools such as > +uscan or mk-origtargz can use > +this information as instructions on how to automatically repack an > + upstream source distribution into one suitable for use within Debian. Nice. -- Sean Whitton
Bug#998165: debian-policy: document and allow Description in the source paragraph
Hello Mattia, Russ, Thank you both for your input on this. On Mon 27 Dec 2021 at 09:51PM +01, Mattia Rizzolo wrote: > In my mind I was mostly focusing on being able to provide a > **description for the source package** (that is, then, relevant to > everything that source package builds); said description being picked up > by a substvar and used again later on is more like a nicety that comes > after describing the source first. On Mon 27 Dec 2021 at 01:53PM -08, Russ Allbery wrote: > Mattia Rizzolo writes: > >> |+When used in a source control file in the general paragraph (i.e., the >> |+first one, for the source package), the text in this field is used to >> |+describe the source package itself, and consequently all of the binary >> |+packages built from itself. > > What if we just left off that paragraph entirely? I'm not sure it's > adding anything. The new text would then read: > >In a source or binary control file, the ``Description`` field contains a >description of the package, consisting of two parts, the synopsis or >the short description, and the long description. > > If it's in a source control file, it's a description of the source > package; if it's in a binary control file, it's a description of the > binary package. That seems obvious, so I'm not sure we need to say it > explicitly. I had actually been thinking that the only point of a Description: field in the source package paragraph was for the sake of substituting it into binary package descriptions. Could those who have been involved in non-Policy discussions of source package paragraph Description: fields confirm that the purposes here really is to add descriptions for source packages, as well as to provide something to substitute? Introducing descriptions for source packages seems fine, but I want to be surer of our intent. > That said, 5.6.13 currently technically doesn't document Description for a > source package control file, only for source or binary control files or > (later, with entirely different syntax) for *.changes files. Maybe that's > the root of the problem. In that case, I think the paragraph we need is: > >The ``Description`` fields in source package control files are used to >construct the ``Description`` fields for the source and binary control >files when the package is built. Any ``Description`` field in the >first paragraph of the source package control file becomes the >description of the source package for the source binary control file. >``Description`` fields in subsequent paragraphs become the description >of the corresponding binary packages. See deb-substvars(5) for some >substitution variables that may be useful when writing binary package >descriptions, such as ``source:Synopsis`` and >``source:Extended-Description``. Looks good, once my question above is addressed. > BTW, I think "3.4 The description of the package" may also need some minor > updates. At the least, "Every Debian package" should probably say "Every > Debian binary package" since I don't think we're requiring source packages > to have descriptions. It may also be worth adding a paragraph explaining > that source packages may have descriptions as well, but are not required > to. Right. I don't think we even want to recommend them at this point. I would not like to put any pressure on maintainers to write them. -- Sean Whitton signature.asc Description: PGP signature
Bug#998165: debian-policy: document and allow Description in the source paragraph
Hello Guillem, Mattia, On Fri 24 Dec 2021 at 01:42PM +01, Guillem Jover wrote: > On Tue, 2021-12-21 at 17:53:31 -0700, Sean Whitton wrote: >> >> Is there really no name for the first paragraph other than "general >> paragraph"? > > That's how the dpkg documentation (man and perl modules POD) refers to > it (or first block of information, which is even worse), but I agree > it's rather suboptimal, and I'd like to get a better name for it. See > below. Okay, fair enough, then let's just use "general paragraph" for now. > For example we have «Debian source control file» or «Debian source > packages' control file» for .dsc, then we have «Source package control > file» or in dpkg «Debian source packages' master control file» for > debian/control. Which are almost the same. I've been considering naming > debian/control something like «Debian template source control file», as > that is used to generate both the source and binary control files. > > But I think I'll open a new bug to cover and discuss that. Cool. >> Also, how about "the text in this field describes all binary packages >> which do not have their own Description: fields" ? > > I'm not sure whether you are (or the text would then) imply this; but > the Description in the source stanza does not get inherited by the > binary stanzas when generating the binary package control file, one > needs to add references to it via substvars. Oh, right. In that case, returning to Mattia's patch, it is probably not correct to say that the source Description is relevant for all binary packages, because perhaps the substvar is used for some but not all of them? -- Sean Whitton signature.asc Description: PGP signature
Bug#1002626: debian-policy: building packages should not require to be root
Hello Russ, On Sat 25 Dec 2021 at 06:45PM -08, Russ Allbery wrote: > Vincent Lefevre writes: >> On 2021-12-25 14:48:33 -0800, Russ Allbery wrote: >>> Vincent Lefevre writes: > >>>> Here, the build via "debuild" is failing even when fakeroot is >>>> available (installed on the machine). Note that Rules-Requires-Root >>>> has been set to "no". IMHO, the policy should say that when >>>> Rules-Requires-Root is set to "no", being root or using fakeroot >>>> should not be required. > >>> It does already. > >>> no: Declares that neither root nor fakeroot is required. Package >>> builders (e.g. dpkg-buildpackage) may choose to invoke any target in >>> debian/rules with an unprivileged user. > >>> Am I missing something? > >> According to Sean, this is just advisory (and Scott Kitterman seemed >> to assume that a build failure as non-root[*] was not a RC bug). > > I don't understand what "advisory" means here. This field controls the > behavior of the package building software. If the package says that root > isn't required, the package will be built without root. If root turns out > to be required, the package will FTBFS. There's nothing "advisory" about > having inaccurate package metadata that causes FTBFS, surely? I said that the requirement is only advisory based on how there is no requirement on packages expressed must/should/etc. in the description of Rules-Requires-Root: no in Policy. The target of the advice would be authors and maintainers of package builders. However, I missed the use of "required" in the text, which means there is in fact a Policy requirement not to fail to build as non-root when this field value is declared, I think? Sorry for causing some confusion here. -- Sean Whitton signature.asc Description: PGP signature
Bug#1002626: debian-policy: building packages should not require to be root
control: retitle -1 When Rules-Require-Root: no, packages should not fail to build as non-root Hello Vincent, On Sat 25 Dec 2021 at 11:37PM +01, Vincent Lefevre wrote: > When a package is built as a normal user, Rules-Requires-Root assumes > that using fakeroot would be fine. > > Here, the build via "debuild" is failing even when fakeroot is > available (installed on the machine). Note that Rules-Requires-Root > has been set to "no". IMHO, the policy should say that when > Rules-Requires-Root is set to "no", being root or using fakeroot > should not be required. Okay, I've attempted to retitle this bug in accordance with your suggestion. The relevant change would not be in ch. 4, but under ch. 5. What you suggest is to add to the meaning of "Rules-Requires-Root: no" that packages which declare this must not fail to build as non-root. This would be quite a significant change, as currently Rules-Requires-Root is pretty much just advisory to dpkg-buildpackage. Do we have a project consensus that it ought to be more than advisory? I'm not sure -- the field is fairly new. In addition to that, we would also need to be confident that making this change in Policy would not render more than a few packages buggy. -- Sean Whitton signature.asc Description: PGP signature
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
nicode.org/>`_ characters, with the > eighth bit always zero. > > +upstream > +The source of software that is being packaged, or the portion of a > +software package that originates from outside of Debian. For example, > +suppose Alice writes and releases a free software package, and then > +Bob creates a Debian package of that software package. Alice is the > +*upstream maintainer* (sometimes abbreviated as *upstream*) of the > +package, Alice's releases are the *upstream releases*, and the version > +number she puts on a release is the *upstream version*. Bob may make > +Debian-specific modifications to the package, and then later send > +those modifications *upstream* to be incorporated in Alice's releases. > + > +The packager and upstream developer may be the same person. For > +example, Alice may choose to package her own software for Debian. > +However, this manual still distinguishes between the role of upstream > +and the role of Debian packager, even when the same person is filling > +both of those roles, since they have some implications for the details > +of packaging. > + > UTF-8 > The transformation format (sometimes called encoding) of > `Unicode <http://www.unicode.org/>`_ defined by `RFC > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index edae8c1..d6fbfc7 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -1,6 +1,37 @@ > +.. _s-source-packages: > + > Source packages > === > > +A Debian source package contains the source material used to construct one > +or more :doc:`binary packages `. A source package consists of > +a ``.dsc`` file (see :ref:`s-debiansourcecontrolfiles`), one or more > +compressed tar files, and possibly other files depending on the type and > +format of source package. Binary packages are contructed from the source > +package via a build process defined by ``debian/rules`` and other files in > +the ``debian`` directory of the unpacked source package. > + > +Debian source packages are classified as *native* or *non-native*. > + > +A native source package is one that does not distinguish between Debian > +packaging and upstream releases. A native source package contains a > +single tar file of source material, and the versioning does not have a > +Debian-specific component. Native packages are normally (but not > +exclusively) used for software that has no independent existence outside > +of Debian, such as software written specifically to be a Debian package. > + > +A non-native source package separates the upstream release from the Debian > +packaging and any Debian-specific changes. The source in a non-native > +source package is divided into one or more upstream tar files plus a > +collection of Debian-specific files. (Depending on the format of the > +source package, those Debian-specific files may come in the form of > +another tar file or in the form of a compressed diff.) The version of a > +non-native package has an upstream component and a Debian component, and > +there may be multiple Debian package versions associated with a single > +upstream release version and sharing the same upstream source tar files. > + > +Most source packages in Debian are non-native. > + > .. _s-standardsversion: > > Standards conformance > Seconded, and I've merged your branch to next. Thanks Russ. I made some wording changes and applied Sam's suggestion to flip the ordering of non-native and native stable update versions. I'm also going ahead and applying the following patch which I'm less sure about, because possibly it loses information that you wanted to include -- please feel free to revert or iterate on it. From f3e38e43a72af31abf9ce7bdb614eae1c47249a4 Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Thu, 23 Dec 2021 23:06:50 -0700 Subject: [PATCH] introduce native source packages slightly differently Taking the definitions section in ch. 1 strictly, "upstream releases" refers to the content of upstream's releases, not the events of upstream releasing. So when we say that a native source package does not distinguish between Debian packaging and upstream releases, we mean that there is no distinction made between the debian/ directory and all the rest of the source code. This is true if we are thinking about our source package formats, where for a non-native package there are separate tarballs for debian/ and for the rest of the source code. However, the distinction between native and non-native packages is not inexorably tied to our use of source packages. If someone doesn't have source package formats in mind, the distinction between the debian/ directory and all the rest of the source code is not so salient -- in a se
Bug#999826: debian-policy: fix Build-Depends footnote
control: tag -1 + pending Hello Johannes, On Sat 20 Nov 2021 at 10:52PM +01, Johannes Schauer Marin Rodrigues wrote: > Hi Sean, > > Quoting Sean Whitton (2021-11-19 23:13:46) >> Can you turn this into a patch against our git repo, please? > > maybe I'm looking at the wrong git repo but I didn't find out how to file a > merge request. Thus attaching the git format-patch. Sorry, when I said "against", an e-mailed patch is exactly what I meant, but I see now it was not so clear. Thank you for your patch. I've gone ahead and applied (most of) it, because the improvements to the existing text seem definitely worth having. For now, I've cut out the openssl/gnutls example, because I think it makes the footnote a bit long, and yet it's still quite a tricky example to understand unless you're someone who thinks about wanna-build a lot (not me). Let me know if you really think it should be in there -- or perhaps that bit could go into dev-ref somewhere? -- Sean Whitton signature.asc Description: PGP signature
Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus
Hello Simon,
On Fri 29 Oct 2021 at 11:12AM +01, Simon McVittie wrote:
> We now have two implementations of the D-Bus well-known system bus
> available in Debian:
>
> * dbus, the portable reference implementation
> * dbus-broker, a Linux-specific reimplementation
>
> so it seems like a good time to introduce {default-,}dbus-system-bus
> virtual packages, mirroring {default-,}dbus-session-bus.
>
> At the moment, dbus is the default for all architectures. It is possible
> that dbus-broker might take over as the default on Linux architectures
> in some future release (but it is explicitly not portable, so dbus will
> probably always be the default on kFreeBSD and Hurd, similar to how we
> choose dbus-user-session vs. dbus-launch).
>
> Packages depending on "dbus" can currently count on having most aspects of
> the reference implementation available (except for the session bus, which
> requires either dbus-user-session or dbus-launch), but I would prefer to
> move towards packages explicitly declaring a dependency on one or more of:
>
> * default-dbus-system-bus | dbus-system-bus:
> the well-known system bus, as required by e.g. Avahi, polkit, udisks2
> * dbus-daemon: ability to run the dbus-daemon(1) and dbus-run-session(1)
> executables, or rely on having the D-Bus machine ID /var/lib/dbus/machine-id
> (dbus-session-bus and dbus-system-bus both imply some sort of machine
> ID, but it might be systemd's /etc/machine-id)
> * dbus-bin: ability to run assorted CLI tools such as dbus-send(1) and
> dbus-monitor(1)
>
> Proposed wording attached.
Thank you for this, sounds good to me.
virtual-package-names-list.yaml says that proposed new virtual package
names are meant to be sent to d-devel, not just filed as a bug against
debian-policy, so perhaps you could do that and we'll give it a week,
then I'll go ahead and add these?
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas
Hello Simon, On Fri 29 Oct 2021 at 10:51AM +01, Simon McVittie wrote: > From a332e4e787837cac0856c9c36d6e87e9f19197e2 Mon Sep 17 00:00:00 2001 > From: Simon McVittie > Date: Thu, 9 Sep 2021 15:43:20 +0100 > Subject: [PATCH 1/2] archive: Point out that mixed main/contrib source > packages can exist Thank you for the patches. Would you mind combining them into a single commit? That way it makes more sense to say that applying this does in fact resolve the whole bug. > Signed-off-by: Simon McVittie Please drop this trailer, as it has no semantics for policy.git (we have no DEVELOPER-CERTIFICATE or similar). > +If a source package is in the *main* archive area, then at least one of > +the binary packages that it produces 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`. Minor suggestion: "binary packages it produces" could be just "its binary packages". > +Source packages in *main* with a mixture of *main* and *contrib* binary > +packages should be limited to situations where it would be inconvenient > +to split the source package. [...] How about saying that this is for technical reasons, not anything philosophical? > +In particular, build-dependencies outside *main* are not allowed in > +these source packages, but the *contrib* binary packages may have runtime > +dependencies outside *main*. Please rephrase this in terms of "must" rather than "not allowed". > A source package in non-free cannot produce contrib binary packages, > because we want main + contrib to be self-contained: if you download > all main or contrib source packages, that should give you the source > code of all main and contrib binary packages. I wonder if this idea that we want main+contrib to be self-contained should be included in the text somehow? Or is it obvious? -- Sean Whitton signature.asc Description: PGP signature
Bug#998165: debian-policy: document and allow Description in the source paragraph
Hello Mattia, Thanks for the patch. On Sun 12 Dec 2021 at 06:47PM +01, Mattia Rizzolo wrote: > |--- a/policy/ch-controlfields.rst > |+++ b/policy/ch-controlfields.rst > |@@ -652,9 +654,14 @@ orderings. [#]_ > | ~~~ > | > | In a source or binary control file, the ``Description`` field contains a > |-description of the binary package, consisting of two parts, the synopsis > |-or the short description, and the long description. It is a multiline > |-field with the following format: > |+description of the package, consisting of two parts, the synopsis or the > short > |+description, and the long description. > |+ > |+When used in a source control file in the general paragraph (i.e., the first > |+one, for the source package), the text in this field is relevant for all > binary > |+packages built by the given source package. Is there really no name for the first paragraph other than "general paragraph"? Maybe "the source package's stanza"? Also, how about "the text in this field describes all binary packages which do not have their own Description: fields" ? -- Sean Whitton signature.asc Description: PGP signature
Bug#999826: debian-policy: fix Build-Depends footnote
Hello, On Wed 17 Nov 2021 at 11:10AM +01, Johannes Schauer Marin Rodrigues wrote: > Source: debian-policy > Version: 4.6.0.1 > Severity: normal > X-Debbugs-Cc: jo...@debian.org > > Hi, > > currently, footnote [1] of §7 states: > >> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit >> the use of alternative dependencies, these are not normally used by the >> Debian autobuilders. To avoid inconsistency between repeated builds of a >> package, the autobuilders will default to selecting the first >> alternative, after reducing any architecture-specific restrictions for >> the build architecture in question. While this may limit the usefulness >> of alternatives in a single release, they can still be used to provide >> flexibility in building the same package across multiple distributions >> or releases, where a particular dependency is met by differently named >> packages. > > There are multiple problems with this footnote: > > 1. "they are not normally used by the Debian autobuilders" should >instead be "they are never used by the Debian autobuilders" or it >should state when they are used and when they are not > > 2. the above also omits that they are used in situations where an >alternative has the form pkgA (rel ver1) | pkgA (rel ver2) > > 3. "To avoid inconsistency between repeated builds" suggests that this >measure avoids inconsistency. It does avoid some but since it doesn't >avoid all, it's wrong to say that it does avoid consistency. >Inconsistency is still created by alternatives of binary packages and >by virtual packages. > > So maybe the above can be improved? Here is a suggested new wording for > the first part of the footnote: > >> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit >> the use of alternative dependencies, these are discarded by the Debian >> autobuilders, after reducing any architecture-specific restrictions for >> the build architecture in question, except when the later alternative >> has the same package name as the first alternative. This is to improve >> consistency between repeated builds of a package while still allowing >> version ranges of the same package. Can you turn this into a patch against our git repo, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#998165: debian-policy: document and allow Description in the source paragraph
Hello,
On Sun 31 Oct 2021 at 11:18AM +01, Mattia Rizzolo wrote:
> Package: debian-policy
> Version 4.6.0.0
>
> Hi!
>
> dpkg 1.19.0 introduced, following the request in #555743, a bunch of new
> substvars. Notably, it now handles ${source:Synopsis} and
> ${source:Extended-Description} that are described as follow:
>
>source:Synopsis
>The source package synopsis, extracted from the source stanza
>Description field, if it exists
>
>source:Extended-Description
>The source package extended description, extracted from the
>source stanza Description field, if it exists
>
>
> Currently Policy §5.2 lists the allowed known fields, and Description is
> accepted only in the "binary package paragraphs", not in the one for the
> source package.
>
>
> As documented in the bug report mentioned above, these are the main
> benefits of having a Description in the source paragraph:
> * helps de-duplicate the description in the binary paragraphs (mostly
>relevant for libraries and other packages that build many binaries
>and share a common description). Note that this would only
>de-duplicate d/control, the binary DEBIAN/control of each binary
>package would still keep the generated long description.
> * ship a generic source-level descrption of the package, which just
>make sense if one thinks about it
> * as a consequence of the above, a bunch of tools (DDPO, PTS, etc)
>would be able to drop the weird and unnatural logic that they use to
>pick a description for the source package
> The main "bad" consequence would be that Description would be exported
> in the .dsc and as such end up in the Sources index. This is probably
> what we want anyway, but with all the people complaining about how big
> the index is getting it's something to consider. However it's also true
> that realistically very few packages are going to make use of this
> facility in the near future so it shouldn't really matter IMHO.
Hrm. Could dak be modified to filter this out of the Sources file?
--
Sean Whitton
signature.asc
Description: PGP signature
