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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Niko Tyni-3
(Taking the debian-dpkg list in the loop and hence overquoting.)

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?
> >
> > Well, dpkg and apt allow it for starters.
> >
> > The idea with the perl packages is that the src:perl binary packages
> > offer an older "stable" version of some modules while a newer version is
> > packaged separately and gets installed earlier on the Perl search path
> > (so it overrides the src:perl version when installed.)
> >
> > This has been the case for ages with the src:perl packages Providing
> > an unversioned virtual package. The change here is that the virtual
> > package is now versioned, which would simplify lots of dependencies
> > that currently read like (for instance)
>
> 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)
>
> If yes this seems to me a quite drastic change of the meaning of
> package relations. Has this been discussed somewhere?

Not that I know of. I've been just going by what works with dpkg and
apt. If this is something that has only been made possible accidentally,
I'll of course back up the src:perl changes.

@debian-dpkg: could you please comment.
--
Niko Tyni   [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Guillem Jover
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.

> > > Well, dpkg and apt allow it for starters.

Yes.

> > > The idea with the perl packages is that the src:perl binary packages
> > > offer an older "stable" version of some modules while a newer version is
> > > packaged separately and gets installed earlier on the Perl search path
> > > (so it overrides the src:perl version when installed.)
> > >
> > > This has been the case for ages with the src:perl packages Providing
> > > an unversioned virtual package. The change here is that the virtual
> > > package is now versioned, which would simplify lots of dependencies
> > > that currently read like (for instance)
> >
> > 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.

If this is not desirable, one could always Conflicts/Breaks on the
virtual package from within each provider for example.

> > 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! :)

The fact that you can concoct strange or invalid relationships does not
mean one has to do it. You could also for example Depends and Conflicts
on the same package and similar.

> Not that I know of. I've been just going by what works with dpkg and
> apt. If this is something that has only been made possible accidentally,
> I'll of course back up the src:perl changes.

This was pretty much intentional. And the usage in perl seems completely
as this was implemented for.

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

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

Ralf Treinen
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.

Reply | Threaded
Open this post in threaded view
|

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

Adrian Bunk-3
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:
>
> 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 ?

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?

> Cheeers -Ralf.

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

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

Ralf Treinen
On Wed, Jul 05, 2017 at 11:02:52PM +0300, Adrian Bunk wrote:

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

Excellent. The fact that real packages can be installed in only one
version is used to encode an interval constraint: "p(>=1), p(<<2)"
means "p in some version between 1 (inclusive) and 2 (eclusive)".
Now, this breaks down with virtual packages since they can be
installed in multiple versions at the same time.

-Ralf.

Reply | Threaded
Open this post in threaded view
|

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

Guillem Jover
In reply to this post by Adrian Bunk-3
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

Reply | Threaded
Open this post in threaded view
|

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

Adrian Bunk-3
On Thu, Jul 06, 2017 at 04:26:04AM +0200, Guillem Jover wrote:

> On Wed, 2017-07-05 at 23:02:52 +0300, Adrian Bunk wrote:
>...
> > 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.
>...

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}

> Thanks,
> Guillem

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

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

Sven Joachim
On 2017-07-06 12:02 +0300, Adrian Bunk wrote:

> On Thu, Jul 06, 2017 at 04:26:04AM +0200, Guillem Jover wrote:
>> On Wed, 2017-07-05 at 23:02:52 +0300, Adrian Bunk wrote:
>>...
>> > 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.
>>...
>
> 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".

Which is not totally inconceivable, but seems unlikely at the moment.

Cheers,
       Sven

Reply | Threaded
Open this post in threaded view
|

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

Guillem Jover
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.

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

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

Adrian Bunk-3
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.

"Depends: p (>= 1), p (<< 2)" is a common pattern, and with the changed
semantics it is no longer correct in all cases.

As far as I can see we should deprecate using << or <= in Depends,
including a lintian error for any usage.

> Thanks,
> Guillem

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

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

Guillem Jover
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

Reply | Threaded
Open this post in threaded view
|

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

gregor herrmann-3
In reply to this post by Guillem Jover
On Wed, 05 Jul 2017 03:01:10 +0200, Guillem Jover wrote:

> On Tue, 2017-07-04 at 23:30:37 +0300, Niko Tyni wrote:
> > Not that I know of. I've been just going by what works with dpkg and
> > apt. If this is something that has only been made possible accidentally,
> > I'll of course back up the src:perl changes.
>
> This was pretty much intentional. And the usage in perl seems completely
> as this was implemented for.

That's good to hear as we'd really like to use versioned provides
this way in th perliverse :)


On Thu, 06 Jul 2017 04:26:04 +0200, Guillem Jover wrote:

> > 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 for all your explanations!


Now that all cases, including the 6th one, are clear, is there
anything that's missing before the behaviour of dose-builddebcheck
can be adapted?


Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Billy Joel: We Didn't Start the Fire

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ralf Treinen
On Tue, Jul 11, 2017 at 11:43:08PM +0200, gregor herrmann wrote:

> Now that all cases, including the 6th one, are clear, is there
> anything that's missing before the behaviour of dose-builddebcheck
> can be adapted?

I am working on it. -Ralf.

Reply | Threaded
Open this post in threaded view
|

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

gregor herrmann-3
On Thu, 13 Jul 2017 08:49:06 +0200, Ralf Treinen wrote:

> On Tue, Jul 11, 2017 at 11:43:08PM +0200, gregor herrmann wrote:
> > Now that all cases, including the 6th one, are clear, is there
> > anything that's missing before the behaviour of dose-builddebcheck
> > can be adapted?
> I am working on it. -Ralf.

Excellent, thanks alot!


Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rebekka Bakken & Wolfgang Muthspiel: Wonders

signature.asc (981 bytes) Download Attachment