On Fri, Jun 07, 2019 at 09:44:10AM +0100, Simon McVittie wrote:
> On Thu, 06 Jun 2019 at 21:54:40 +0100, Dominic Hargreaves wrote:
> > This is a fair comment. The wording was potentially misleading. How about
> > the attached instead?
>
> This mostly looks good, just one thing that I would add:
>
> > -If a relationship field has a version number attached, only real
> > -packages will be considered to see whether the relationship is satisfied
> > -(or the prohibition violated, for a conflict or breakage). In other
> > -words, if a version number is specified, this is a request to ignore all
> > -``Provides`` for that package name and consider only real packages. The
> > -package manager will assume that a package providing that virtual
> > -package is not of the "right" version. A ``Provides`` field may not
> > -contain version numbers, and the version number of the concrete package
> > -which provides a particular virtual package will not be considered when
> > -considering a dependency on or conflict with the virtual package name.
> > -[#]_
> > +A ``Provides`` field may contain version numbers, and such a version number
> > +will be considered when considering a dependency on or conflict with the
> > +virtual package name. [#]_ For example, given the following packages:
> > +
> > +::
> > +
> > + Package: foo
> > + Depends: bar (>= 1.0)
> > +
> > + Package: bar
> > + Version: 0.9
> > +
> > + Package: bar-plus
> > + Provides: bar (= 1.0)
> > +
> > +the ``bar-plus`` package will again satisfy the dependency for
> > +the ``foo`` package.
>
> I think it's still worth saying explicitly that an unversioned Provides
> doesn't satisfy any versioned dependencies or violate any versioned
> conflicts:
>
> ---
> ... with the virtual package name. [#]_ If the ``Provides`` field does
> not specify a version number, it will not satisfy versioned dependencies
> or violate versioned ``Conflicts`` or ``Breaks``. For example, given the
> following packages:
>
> ::
>
> Package: foo
> Depends: bar (>= 1.0)
>
> Package: bar
> Version: 0.9
>
> Package: bar-plus
> Provides: bar (= 1.0)
>
> Package: bar-clone
> Provides: bar
>
> the ``bar-plus`` package will satisfy the dependency for the ``foo``
> package, but the ``bar-clone`` package will not.
> ---
Thanks, I agree this is a good addition.
> I wasn't sure what happens for versioned Conflicts and Breaks on
> an unversioned Provides, so I tried it, and the answer is that an
> unversioned Provides is ignored by versioned Breaks: for example ack
> Breaks ack-grep (<< some version), and I was able to install a test
> package with "Provides: ack-grep" without removing ack. It would be
> possible to expand the example to demonstrate this:
>
> ---
> For example, given the following packages:
>
> ::
>
> Package: foo
> Depends: bar (>= 1.0)
>
> Package: bar
> Version: 0.9
>
> Package: bar-plus
> Provides: bar (= 1.0)
>
> Package: bar-clone
> Provides: bar
>
> Package: no-old-bar
> Breaks: bar (<< 2.0)
>
> the ``bar-plus`` package will satisfy the dependency for the ``foo``
> package, but the ``bar-clone`` package will not. Similarly, installing the
> ``no-old-bar`` package will not allow the ``bar-plus`` package to be
> configured, but the ``no-old-bar`` and ``bar-clone`` packages can be
> installed simultaneously without error.
> ---
>
> but perhaps that's sufficiently niche as to make the example more
> rather than less confusing?
Yes, I would say this is too much detail for policy, as it's an edge
case. I also don't think it's a new behaviour, since unversioned Provides
have always behaved this way.
New patch attached.
Thanks,
Dominic.
>From 2779a5280c9e1043be971041f3489151ac06842b Mon Sep 17 00:00:00 2001
From: Dominic Hargreaves <d...@earth.li>
Date: Tue, 1 Jan 2019 18:36:54 +0000
Subject: [PATCH] Remove restrictions on versioned Provides.
Thanks to Simon McVittie for additional wording.
Closes: #761219
---
policy/ch-relationships.rst | 67 +++++++++++++++++++++++++++++++--------------
1 file changed, 46 insertions(+), 21 deletions(-)
diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 1d790e8..3b68420 100644
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -17,15 +17,16 @@ package names, separated by vertical bar (pipe) symbols ``|``. In such a
case, that part of the dependency can be satisfied by any one of the
alternative packages. [#]_
-All of the fields except for ``Provides`` may restrict their
-applicability to particular versions of each named package. This is done
-in parentheses after each individual package name; the parentheses
-should contain a relation from the list below followed by a version
-number, in the format described in :ref:`s-f-Version`.
+All of the fields may restrict their applicability to particular versions
+of each named package. This is done in parentheses after each individual
+package name; the parentheses should contain a relation from the list
+below followed by a version number, in the format described in
+:ref:`s-f-Version`.
The relations allowed are ``<<``, ``<=``, ``=``, ``>=`` and ``>>`` for
strictly earlier, earlier or equal, exactly equal, later or equal and
-strictly later, respectively. [#]_
+strictly later, respectively. The exception is the Provides field, for
+which only ``=`` is allowed. [#]_
Whitespace may appear at any point in the version specification subject
to the rules in :ref:`s-controlsyntax`, and must appear
@@ -446,17 +447,43 @@ they can say:
and the ``bar-plus`` package will now also satisfy the dependency for
the ``foo`` package.
-If a relationship field has a version number attached, only real
-packages will be considered to see whether the relationship is satisfied
-(or the prohibition violated, for a conflict or breakage). In other
-words, if a version number is specified, this is a request to ignore all
-``Provides`` for that package name and consider only real packages. The
-package manager will assume that a package providing that virtual
-package is not of the "right" version. A ``Provides`` field may not
-contain version numbers, and the version number of the concrete package
-which provides a particular virtual package will not be considered when
-considering a dependency on or conflict with the virtual package name.
-[#]_
+A ``Provides`` field may contain version numbers, and such a version number
+will be considered when considering a dependency on or conflict with the
+virtual package name. [#]_ For example, given the following packages:
+
+::
+
+ Package: foo
+ Depends: bar (>= 1.0)
+
+ Package: bar
+ Version: 0.9
+
+ Package: bar-plus
+ Provides: bar (= 1.0)
+
+the ``bar-plus`` package will again satisfy the dependency for
+the ``foo`` package with the virtual package name. [#]_ If the ``Provides``
+field does not specify a version number, it will not satisfy versioned
+dependencies or violate versioned ``Conflicts`` or ``Breaks``. For example,
+given the following packages:
+
+::
+
+ Package: foo
+ Depends: bar (>= 1.0)
+
+ Package: bar
+ Version: 0.9
+
+ Package: bar-plus
+ Provides: bar (= 1.0)
+
+ Package: bar-clone
+ Provides: bar
+
+the ``bar-plus`` package will satisfy the dependency for the ``foo``
+package, but the ``bar-clone`` package will not.
To specify which of a set of real packages should be the default to
satisfy a particular dependency on a virtual package, list the real
@@ -670,10 +697,8 @@ dependencies.
together and then configured in their dependency order.
.. [#]
- It is possible that a future release of ``dpkg`` may add the ability
- to specify a version number for each virtual package it provides.
- This feature is not yet present, however, and is expected to be used
- only infrequently.
+ This functionality was introduced in dpkg 1.17.11 and newer and
+ full support has been provided in the Debian archive since 2018.
.. [#]
To see why ``Breaks`` is normally needed in addition to ``Replaces``,
--
2.11.0
