[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#761219: debian-policy: document versioned Provides



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


Reply to: