Processed: tagging 542288
Processing commands for cont...@bugs.debian.org: > tags 542288 + pending Bug #542288 [debian-policy] Versions for native packages, NMU's, and binary only uploads Bug #850729 [debian-policy] debian-policy: Documenting special version number suffixes Added tag(s) pending. Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 542288: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542288 850729: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850729 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Hello, On Fri 02 Apr 2021 at 10:22AM -07, Russ Allbery wrote: > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index a21a510..2fd6868 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -582,20 +582,17 @@ The three components here are: > alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop, > tilde) and is compared in the same way as the ``upstream_version`` is. > > -It is optional; if it isn't present then the ``upstream_version`` > -may not contain a hyphen. This format represents the case where a > -piece of software was written specifically to be a Debian package, > -where the Debian package source must always be identical to the > -pristine source and therefore no revision indication is required. > +It is conventional to restart the ``debian_revision`` at ``1`` each > +time the ``upstream_version`` is increased. > > -It is conventional to restart the ``debian_revision`` at ``1`` > -each time the ``upstream_version`` is increased. > +The package management system will break the version number apart at > +the last hyphen in the string (if there is one) to determine the > +``upstream_version`` and ``debian_revision``. The absence of a > +``debian_revision`` is equivalent to a ``debian_revision`` of ``0``. > > -The package management system will break the version number apart > -at the last hyphen in the string (if there is one) to determine > -the ``upstream_version`` and ``debian_revision``. The absence of a > -``debian_revision`` is equivalent to a ``debian_revision`` of > -``0``. > +Presence of the ``debian_revision`` part indicates this package is a > +non-native package (see :ref:`s-source-packages`). Absence indicates > +the package is a native package. > > When comparing two version numbers, first the epoch of each are > compared, then the ``upstream_version`` if epoch is equal, and then > @@ -625,6 +622,8 @@ These two steps (comparing and removing initial non-digit > strings and > initial digit strings) are repeated until a difference is found or both > strings are exhausted. > > +.. _s-avoid-epochs: > + > Epochs should be used sparingly > ^^^ > > @@ -639,13 +638,132 @@ Epochs should not be used when a package needs to be > rolled back. > In that case, use the ``+really`` convention: for example, if you > uploaded ``2.3-3`` and now you need to go backwards to upstream 2.2, > call your reverting upload something like ``2.3+really2.2-1``. > -Eventually, when we upload upstream 2.4, the +really part can go away. > +Eventually, when we upload upstream 2.4, the ``+really`` part can go away. > > Epochs are also not intended to cope with version > numbers containing strings of letters which the package management > system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly > orderings. [#]_ > > +Special version conventions > +^^^ > + > +The following special version numbering conventions are used in the Debian > +archive: > + > +- The absence of ``debian_revision``, and therefore of a hyphen in the > + version number, indicates that the package is native. > + > +- The presence of ``+really`` in the ``upstream_version`` component > + indicates that a newer upstream version has been rolled back to an older > + upstream version. The part of the ``upstream_version`` component > + following ``+really`` is the true upstream version. See > + :ref:`s-avoid-epochs` for an example of when this is used. > + > +Non-maintainer uploads: > + > +- ``debian_revision`` components ending in ``.`` (period) followed by a > + number indicate this version of the non-native package was uploaded by > + someone other than the maintainer (an NMU or non-maintainer upload). > + This is used for a source package upload; for uploads of only binary > + packages without source changes, see the binary NMU convention below. > + > +- ``upstream_version`` components in native packages ending in ``+nmu`` > + followed by a number indicate an NMU of a native package. As with the > + convention for non-native packages, this is used for a source package > + upload, not for uploads of only binary packages without source changes. > + > +- ``upstream_version`` components in native packages or > + ``debian_revision`` components in non-native packages ending in ``+b`` > + followed by a number indicate a binary NMU: an upload of a binary > + package without any source changes and hence without any corresponding > + source package upload or version change. > + > +Stable updates: > + > +- ``upstream_version`` components in native packages ending in ``+debNuX`` > + indicate a stable update. This is a version of the package uploaded > + directly to a stable release, and the version is chosen to sort before > + any later version of the package uploaded to Debian's unstable or a > +
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
Processed: Re: Bug#999826: debian-policy: fix Build-Depends footnote
Processing control commands: > tag -1 + pending Bug #999826 [src:debian-policy] debian-policy: fix Build-Depends footnote Added tag(s) pending. -- 999826: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999826 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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
