On Fri, 2017-07-07 at 10:38:26 +0300, Adrian Bunk wrote:
> On Fri, Jul 07, 2017 at 05:20:49AM +0200, Guillem Jover wrote:
> > On Thu, 2017-07-06 at 16:39:44 +0200, Sven Joachim wrote:
> > > On 2017-07-06 12:02 +0300, Adrian Bunk wrote:
> > > > But it is being used for that purpose in *many* packages.
> > > >
> > > > As an example, there are ~ 300 Python3 packages that have
> > > > "python3 (<< 3.7), python3 (>= 3.5~)" dependencies autogenerated using:
> > > >
> > > > Depends: ${python3:Depends}
> > > >
> > > > If this is considered a bug, then what is required is that dh-python
> > > > adds
> > > > ${python3:Breaks}, and then each of these packages has to be changed to:
> > > >
> > > > Depends: ${python3:Depends}
> > > > Breaks: ${python3:Breaks}
> > >
> > > This will only necessary when (or rather if) some contender for the
> > > python3 package comes along that is co-installable with the real python3
> > > package and has a legitimate reason to "Provides: python3".
> >
> > Exactly. We do not tend to use dependencies in a defensive way, and
> > in general base many of them on the current state of the archive. And
> > we tend to remove those whenever they apply only to oldstable or
> > older. Otherwise for example Conflicts/Breaks could become unbounded.
>
> That's a different issue.
> We are not discussing whether or not to add a dependency,
> we are only discussing whether to use a << Depends or a Breaks.
Well, using Breaks here would be adding and using dependencies in an
unnecessarily defensive way. And using << in Depends still looks
correct in this specific case.
> "Depends: p (>= 1), p (<< 2)" is a common pattern, and with the changed
> semantics it is no longer correct in all cases.
Whenever that is not correct then it might need fixing. It is still
correct for the python cases.
This might call at most for an archive-wide periodic check that looks
for any virtual package provided by more than one package (that is not
only a set of M-A:same instances), and is depended on by a versioned
range in Pre-Depends or Depends. And even if any triggered, they'd need
investigation because they might not automatically cause breakage.
> As far as I can see we should deprecate using << or <= in Depends,
> including a lintian error for any usage.
I don't see why, really. This being a bug depends on what kind of
interface is being provided, how it is being used, and then on the
above conditions to be fulfilled in the archive. Otherwise it's just
like any other potential breakage that might happen with the presence
of external packages or similar.
In many cases getting into this kind of situation might imply that the
new providers incur in policy violations; being able to provide a
correct alternative virtual package might simply require cooperation
from the real package or it might just be unfesible.
So, is this pattern inherently broken? IMO no, and as such it needs no
banning. Is this a potentially non-obvious trap that should be made
more visible? Sure, I'll try to cover this in the new deb-dependency(7)
man page for example. Is this something we should watch out, that can
potentially cause breakage? Definitely yes.
Thanks,
Guillem
