Re: Bug#867104: wanna-build issue with src:perl versioned Provides

[Guillem Jover <guillem@debian.org>]

On Wed, 2017-07-05 at 23:02:52 +0300, Adrian Bunk wrote:
> On Wed, Jul 05, 2017 at 09:30:05PM +0200, Ralf Treinen wrote:
> > I guess I am not the only one who does not understand the consequences
> > of versionend provides, and what they mean exaxtly. Part of the problem
> > is of course that policy is still at the state of unversionend provides
> > only. I think it would be useful for many people in the project if the
> > consequences of versionend provides could be documented somewhere. For
> > instance on the dpkg wiki pages (and announcing this on debian-devel),
> > until this finds its way into policy. For instance, here are some questions
> > I have been asking myself:

This should ideally (and in principle) be all documented in the dpkg man
pages or other accompanying documents, as dpkg and its behavior should
stand alone, given that in some cases those diverge from Debian Policy,
either because of policy trailing or because policy only allows a subset
of it, and because dpkg is used beyond Debian and its policy. So I'd
consider any such omission a bug.

And in this particular case this is indeed not very well covered, and
specifically the dependency behavior in general is very thin. Something
I had already started to work on a couple of weeks ago. For starters,
I'm going to be moving all dependency information into a new
deb-dependency(7) man page (or similar), where I'll expand on the
arch-qualified and versioned Provides behaviors among others.

The three relevant commits are:

  <https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=5bb02fe8>
  <https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=5cc36d8e>
  <https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=453d6bfd>

BTW you might also be intersted in the battery of functional tests
covering versioned Provides in:

  <https://anonscm.debian.org/cgit/dpkg/dpkg-tests.git/tree/t-provides>
  <https://anonscm.debian.org/cgit/dpkg/dpkg-tests.git/tree/t-provides-self>

> > 1) policy is obviously outdated when saying that a versionend dependency (or
> > conflict) only concerns relations to real packages, not virtual ones.
> > Assume we have:
> > 
> > Package: a
> > Version: 42
> > 
> > Package: b
> > Version: 73
> > Provides: a (=42)
> > 
> > Certainly, a dependency on a (=42) can be satisfied by any of these two?

Yes, satisfied.

> > 2) Assume we have:
> > 
> > Package: a
> > Depends: v (=1)
> > 
> > Package: b
> > Provides: v
> > 
> > Am I right that a cannot be installed, as b does not satisfy its
> > dependency?

Yes, unsatisfied.

> > 3) Assume we have
> > 
> > Package: a
> > Depends: v
> > 
> > Package: b
> > Provides: v (=1)
> > 
> > That one seems easy: b satisfies the dependency of a on v, so a can be
> > installed?

Yes, satisfied.

> > 4)
> > 
> > Package: a
> > Conflicts: v
> > 
> > Package: b
> > Provides: v (=1)
> > 
> > Are a and b in conflict?

Yes, conflicted.

> > 5)
> > 
> > Package: a
> > Conflicts: v (=1)
> > 
> > Package: b
> > Provides: v
> > 
> > I guess there is no conflict ?

Yes, unconflicted.

> 6)
> 
> Package: a
> Depends: p (>= 1), p (<< 2)
> 
> Package: b
> Provides: p (=1)
> 
> Package: c
> Provides: p (=2)
> 
> When a and b are installed, can c be installed without removing a?

Yes, because b is enough to satisfy the dependency. This is not a
Conflicts/Breaks field after all.

I think all of Ralf cases are already covered by the functional test
suite, I've just added the one from Adrian.

  <https://anonscm.debian.org/cgit/dpkg/dpkg-tests.git/commit/?id=10b721dc>

Thanks,
Guillem