Hi everybody, On Wed, Jul 05, 2017 at 03:01:10AM +0200, Guillem Jover wrote: > Hi! > > On Tue, 2017-07-04 at 23:30:37 +0300, Niko Tyni wrote: > > On Tue, Jul 04, 2017 at 10:18:08PM +0200, Ralf Treinen wrote: > > > On Tue, Jul 04, 2017 at 10:29:35PM +0300, Niko Tyni wrote: > > > > On Tue, Jul 04, 2017 at 09:09:37PM +0200, Ralf Treinen wrote: > > > > > > > > > thanks for having figured that out. I tend to believe that dose is > > > > > right > > > > > in this case. Since it is not possible to install at the same > > > > > time two different versions of the same real package, the same should > > > > > IMHO hold when one is real and the other virtual. Why should this be > > > > > possible? > > Because it follows the same principle that you can have installed both > the real package and various virtual packages providing that one. This > just takes this further and gives it version(s) too.
OK, that's a good point. > > > So, that means that something like > > > > > > Depends: p (=1), p (=2) > > > > > > suddenly becomes satisfiable (when there is one real package p and > > > one virtual package)? Would you also allow to have the packages p > > > and q installed at the same time, in the following situation: > > > > > > Package: p > > > Version: 1 > > > Provides: v (=1) > > > > > > Package: q > > > Version: 1 > > > Provides: v (=2) > > Yes, this is correct. Alright, I see now why this makes sense. > > > If yes this seems to me a quite drastic change of the meaning of > > > package relations. Has this been discussed somewhere? > > Not in recent times, no, the bug requesting versioned provides was a > bit aged. But the semantics are IMO the obvious ones, and I'm actually > a bit surprised they are surprising! :) 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: 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? 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? 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? 4) Package: a Conflicts: v Package: b Provides: v (=1) Are a and b in conflict? 5) Package: a Conflicts: v (=1) Package: b Provides: v I guess there is no conflict ? Cheeers -Ralf.
