architecture-specific dependencies on virtual packages
 

David Kalnischkies wrote:

> while playing around with the APT code regarding architecture-specific
> dependencies I stumbled over the handling of Provides in that context:
>
> Package: pkga
> Status: install ok installed
> Architecture: i386
> Provides: foo
>
> Package pkgb
> Architecture: amd64
> Conflicts: foo:amd64

Conflicts with an architecture seem kind of like conflicts with a
version. That would mean that that virtual packages wouldn't qualify.
Could that work well in practice?

[...]
> Even more interesting, if I change this conflict to a depends dpkg happily
> installs the package and dpkg --audit gives no indication that a dependency
> is unsatisfied

Likewise.

Thanks for bringing it up,
Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120709123417.GA16950@burratino

architecture-specific dependencies on virtual packages
 

On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> David Kalnischkies wrote:
>> while playing around with the APT code regarding architecture-specific
>> dependencies I stumbled over the handling of Provides in that context:
>>
>> Package: pkga
>> Status: install ok installed
>> Architecture: i386
>> Provides: foo
>>
>> Package pkgb
>> Architecture: amd64
>> Conflicts: foo:amd64
>
> Conflicts with an architecture seem kind of like conflicts with a
> version. That would mean that that virtual packages wouldn't qualify.
> Could that work well in practice?

Probably hard to implement in APT, but I don't think it would help -
or that it would be correct:

If a dependency has no architecture attached we assume that the
dependency is satisfiable only by a package from the same architecture
as the package which has the dependency. So we already have
architecture-specific dependencies, we just do not specific them explicitly.


But dpkg doesn't check the architecture for provides, so any foreign package
can provide a "service". This usually works as most "services" are binary-
independent, but there are also quiet a few where this fails miserably.

As an example:
I highly doubt "phonon:amd64" with a dependency on "phonon-backend" will
work with "phonon-backend-vlc:armel" which provides "phonon-backend".

If phonon-backend would be a normal package only phonon-backend:amd64
could satisfy the dependency, but just because it is virtual the
architecture is no longer important for dpkg. That sounds wrong.

(In the given example, APT will see an unsatisfied dependency
as it handles the provides architecture-dependent.)


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAZ6_fDgxyvbkdyDxVDFsKwoWZfaNLwMEqeeR8to++h4Nbr9+ A@mail.gmail.com">http://lists.debian.org/CAAZ6_fDgxyvbkdyDxVDFsKwoWZfaNLwMEqeeR8to++h4Nbr9+ A@mail.gmail.com

architecture-specific dependencies on virtual packages
 

Hi,

David Kalnischkies wrote:
> On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> Conflicts with an architecture seem kind of like conflicts with a
>> version. That would mean that that virtual packages wouldn't qualify.
>> Could that work well in practice?
>
> Probably hard to implement in APT, but I don't think it would help -
> or that it would be correct:
>
> If a dependency has no architecture attached we assume that the
> dependency is satisfiable only by a package from the same architecture
> as the package which has the dependency. So we already have
> architecture-specific dependencies, we just do not specific them explicitly.

I'm following so far.

> But dpkg doesn't check the architecture for provides, so any foreign package
> can provide a "service". This usually works as most "services" are binary-
> independent, but there are also quiet a few where this fails miserably.
>
> As an example:
> I highly doubt "phonon:amd64" with a dependency on "phonon-backend" will
> work with "phonon-backend-vlc:armel" which provides "phonon-backend".
>
> If phonon-backend would be a normal package only phonon-backend:amd64
> could satisfy the dependency, but just because it is virtual the
> architecture is no longer important for dpkg. That sounds wrong.

I agree here. If I understand correctly, you are saying that it would
be best if a dependency

Package: a
Depends: phonon-backend

should only be satisfied by a package from another architecture with

Package: b
Provides: phonon-backend

if package b also has Multi-Arch: foreign.

This might seem to imply that it would be useful to have an escape
valve

Package: a
Depends: phonon-backend:any

But I don't think so. To know that phonon backends of all
architectures satisfy the dependency, we need to know something about
how the packages providing phonon-backend actually work, so it seems
most sensible to make this dependency only satisfiable by non-virtual
packages.

Does that make sense? Can you help me connect the dots and see how
this relates to the question about Conflicts from before?

Thanks,
Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120713213608.GA31498@burratino

architecture-specific dependencies on virtual packages
 

On Fri, Jul 13, 2012 at 11:36 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> David Kalnischkies wrote:
>> As an example:
>> I highly doubt "phonon:amd64" with a dependency on "phonon-backend" will
>> work with "phonon-backend-vlc:armel" which provides "phonon-backend".
>>
>> If phonon-backend would be a normal package only phonon-backend:amd64
>> could satisfy the dependency, but just because it is virtual the
>> architecture is no longer important for dpkg. That sounds wrong.
>
> I agree here. If I understand correctly, you are saying that it would
> be best if a dependency
>
> Package: a
> Depends: phonon-backend
>
> should only be satisfied by a package from another architecture with
>
> Package: b
> Provides: phonon-backend
>
> if package b also has Multi-Arch: foreign.

Yeap, that is what I would expect and it is what APT currently does.
This thread is a try to understand why dpkg does it differently.
aka: Valid reasons or just a bug?


> This might seem to imply that it would be useful to have an escape
> valve
>
> Package: a
> Depends: phonon-backend:any
>
> But I don't think so. To know that phonon backends of all
> architectures satisfy the dependency, we need to know something about
> how the packages providing phonon-backend actually work, so it seems

We don't really need an "escape value" here. You have no chance to do that
for dependencies on 'real' packages, so why would we need it on virtual?
(beside that :any is already taken by M-A:allowed packages)


> most sensible to make this dependency only satisfiable by non-virtual
> packages.

I can't follow on that one as if you are referring to the example above
we suddenly have no dependencies left which could be satisfied by virtuals.
So you probably lost me somewhere.


> Does that make sense? Can you help me connect the dots and see how
> this relates to the question about Conflicts from before?

Sorry, I tend to write confusing sentences at night
(Not that this would get any better in daylight…).

It's connected to Conflicts in the way that it effects all dependencies.
I just found it first with explicit architecture-specific Conflicts, but
in fact provides are never checked for an architecture, regardless of
dependency type and regardless of a explicitly mentioned architecture or not.


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAZ6_fCZNfFvmqoHbB3S5KB1-7jgFOW_G9mNSaHmt4wiLmyMhg@mail.gmail.com">http://lists.debian.org/CAAZ6_fCZNfFvmqoHbB3S5KB1-7jgFOW_G9mNSaHmt4wiLmyMhg@mail.gmail.com

architecture-specific dependencies on virtual packages
 

David Kalnischkies wrote:
> On Fri, Jul 13, 2012 at 11:36 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> I agree here. If I understand correctly, you are saying that it would
>> be best if a dependency
>>
>> Package: a
>> Depends: phonon-backend
>>
>> should only be satisfied by a package from another architecture with
>>
>> Package: b
>> Provides: phonon-backend
>>
>> if package b also has Multi-Arch: foreign.
>
> Yeap, that is what I would expect and it is what APT currently does.
> This thread is a try to understand why dpkg does it differently.
> aka: Valid reasons or just a bug?

Sounds like just a bug.

[...]
>> most sensible to make this dependency only satisfiable by non-virtual
>> packages.
>
> I can't follow on that one as if you are referring to the example above
> we suddenly have no dependencies left which could be satisfied by virtuals.
> So you probably lost me somewhere.

Yes, you have lost me, too. :)

Let me try again. I believe that a dependency like this:

Depends: package-foo:i386

is referring to a specific, concrete, non-virtual package package-foo
and it doesn't make sense to allow this to be satisfied by virtual
packages.

I understand that neither dpkg nor apt works that way currently, but
that is what I think the right behavior would be.

We can talk about Conflicts later. Let's get this part ironed out
first.

Thanks,
Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120717164633.GH3071@burratino

architecture-specific dependencies on virtual packages
 

On Tue, Jul 17, 2012 at 6:46 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Let me try again. I believe that a dependency like this:
>
> Depends: package-foo:i386
>
> is referring to a specific, concrete, non-virtual package package-foo
> and it doesn't make sense to allow this to be satisfied by virtual
> packages.

My 'believe' is that in this example:
Package: foobar
Architecture: amd64
Depends: package-bar
that last line is in fact read as:
Depends: package-bar:amd64

So it would make sense to handle implicit or explicit specific-arch
dependencies equally.


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAZ6_fBmUEPt3nUucJtucVKW7C8ncsgbP8GNvvir-3uf36v_Zg@mail.gmail.com">http://lists.debian.org/CAAZ6_fBmUEPt3nUucJtucVKW7C8ncsgbP8GNvvir-3uf36v_Zg@mail.gmail.com

architecture-specific dependencies on virtual packages
 

David Kalnischkies wrote:

> in this example:
> Package: foobar
> Architecture: amd64
> Depends: package-bar
> that last line is in fact read as:
> Depends: package-bar:amd64

Why? I don't think that would help humans any more than reading it as

Depends: package-bar (>= -infinity)

(if there were a syntax for -∞). Maybe you are saying that reading
it this way makes the implementation simpler?


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120717184618.GD14609@burratino

architecture-specific dependencies on virtual packages
 

Jonathan Nieder wrote:
> David Kalnischkies wrote:

>> in this example:
>> Package: foobar
>> Architecture: amd64
>> Depends: package-bar
>> that last line is in fact read as:
>> Depends: package-bar:amd64
>
> Why? I don't think that would help humans any more than reading it as
>
> Depends: package-bar (>= -infinity)
>
> (if there were a syntax for -∞).

In fact, that reading seems problematic, though I could easily be
missing something. If package-bar has "Multi-arch: foreign", then
isn't

Architecture: amd64
Depends: package-bar

satisfied by package-bar:i386, while

Architecture: amd64
Depends: package-bar:amd64

is not?


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120717184820.GE14609@burratino

architecture-specific dependencies on virtual packages
 

On Mon, Jul 09, 2012 at 02:00:14PM +0200, David Kalnischkies wrote:
> Hi,
>
> while playing around with the APT code regarding architecture-specific
> dependencies I stumbled over the handling of Provides in that context:
>
> Package: pkga
> Status: install ok installed
> Architecture: i386
> Provides: foo
>
> Package pkgb
> Architecture: amd64
> Conflicts: foo:amd64
>
>
> The result with dpkg (1.16.7):
> dpkg: regarding .../pool/pkgb_1_amd64.deb containing pkgb:
> pkgb conflicts with foo:amd64
> pkga provides foo and is present and installed.
>
>
> Even more interesting, if I change this conflict to a depends dpkg happily
> installs the package and dpkg --audit gives no indication that a dependency
> is unsatisfied (same problem with depends if no architecture is specified).
>
> Shouldn't provides be limited by the architecture their provider can work on?
> Or did I miss something here?
>
>
> Best regards
>
> David Kalnischkies

Imho a Povides creates an alias for the package. So

Package: pkga
Status: install ok installed
Architecture: i386
Provides: foo

should behave identical to

Package: foo
Status: install ok installed
Architecture: i386


Note that the behaviour of a real package changes depending on the
Multi-Arch setting and the same should be true for a provided package.

The only difference with a provides should be that provides don't have
a version.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120718103526.GA5976@frosties