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