Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   M-A: Same package A providing and conflicting with package B (http://www.linux-archive.org/debian-dpkg/703647-m-same-package-providing-conflicting-package-b.html)

Johannes Schauer 09-13-2012 09:22 PM

M-A: Same package A providing and conflicting with package B
 
Hi,

up to version 3.1, dose3 limited Conflicts of a package A to the
architecture of A. Bug#685171 addressed this issue, and as a result,
dose3 now adds conflicts for every architecture. Now, if A conflicts
with B, it conflicts with B in all its architectures.

Unfortunately, this behavior breaks the following class of packages:

Packages which are M-A: Same and provide a virtual package with which
they also conflict.

An example for such a package is linux-libc-dev. It is M-A: Same and
also:

Replaces: linux-kernel-headers
Provides: linux-kernel-headers
Conflicts: linux-kernel-headers

As I learned, the above means, that there must be only one package
providing linux-kernel-headers.

The problem is, that with linux-libc-dev conflicting with
linux-kernel-headers of all arches, linux-libc-dev is not co-installable
with itself anymore even though it is M-A: Same.

Example on an i386/amd64 system:

linux-libc-dev:amd64 provides linux-kernel-headers:amd64 and conflicts
with linux-kernel-headers:amd64 and linux-kernel-headers:i386.

linux-libc-dev:i386 provides linux-kernel-headers:i386 and conflicts
with linux-kernel-headers:amd64 and linux-kernel-headers:i386.

If linux-libc-dev:amd64 is installed, one can not install
linux-libc-dev:i386 anymore even though linux-libc-dev is M-A: Same.

The reason is, that linux-libc-dev:amd64 provides
linux-kernel-headers:amd64 with which linux-libc-dev:i386 conflicts.
Also, linux-libc-dev:i386 provides linux-kernel-headers:i386 with which
linux-libc-dev:amd64 conflicts.

The dilemma is solved by having all packages A that provide as well as
conflict with a package B and are also M-A: Same only conflict with B of
their own architecture and NOT all architectures.

This conclusion doesnt seem obvious to me and I didnt find it written
down somewhere.

So my question: is the following conclusion correct

> If a package A:$arch conflicts with a package B, then A:$arch
> conflicts with package B in all architectures EXCEPT if A is M-A: Same
> AND A also provides B. In this case, A:$arch only conflicts with
> B:$arch and NOT with B in all its architectures as it would be the
> default.

And if it is correct, should it be written down somewhere?

Also, if it is correct, is there a more general rule?

And are there more rules that are similar to this one?

This rule is for Provides but what about Replaces?

cheers, josch


--
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/20120913212240.GA27285@hoothoot

Jonathan Nieder 09-13-2012 09:28 PM

M-A: Same package A providing and conflicting with package B
 
Johannes Schauer wrote:

> As I learned, the above means, that there must be only one package
> providing linux-kernel-headers.
>
> The problem is, that with linux-libc-dev conflicting with
> linux-kernel-headers of all arches, linux-libc-dev is not co-installable
> with itself anymore even though it is M-A: Same.

That does sound like a bug. The intuitive behavior when foo both
Provides and Conflicts with bar would be for the Conflicts to only
apply to other packages.

Thanks,
Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913212829.GB177@mannheim-rule.att.net">http://lists.debian.org/20120913212829.GB177@mannheim-rule.att.net

Russ Allbery 09-13-2012 11:26 PM

M-A: Same package A providing and conflicting with package B
 
Jonathan Nieder <jrnieder@gmail.com> writes:
> Johannes Schauer wrote:

>> As I learned, the above means, that there must be only one package
>> providing linux-kernel-headers.

>> The problem is, that with linux-libc-dev conflicting with
>> linux-kernel-headers of all arches, linux-libc-dev is not
>> co-installable with itself anymore even though it is M-A: Same.

> That does sound like a bug. The intuitive behavior when foo both
> Provides and Conflicts with bar would be for the Conflicts to only
> apply to other packages.

Indeed. This particular combination of package metadata has a specific
meaning defined in Policy 7.4:

A special exception is made for packages which declare a conflict with
their own package name, or with a virtual package which they provide
(see below): this does not prevent their installation, and allows a
package to conflict with others providing a replacement for it. You
use this feature when you want the package in question to be the only
package providing some feature.

So you need to specifically recognize the case of Conflicts naming the
package itself or a virtual package that this package provides, and in
that case the Conflicts should not be applied to that package for
installability determination.

None of this language has, as yet, been updated for multiarch, but I think
it makes logical sense for a M-A: same package to be coinstallable even if
it Conflicts with its own package name or a virtual package it Provides,
by extension from the intention of this construct without multiarch.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877grx8pys.fsf@windlord.stanford.edu">http://lists.debian.org/877grx8pys.fsf@windlord.stanford.edu

Johannes Schauer 09-14-2012 09:29 AM

M-A: Same package A providing and conflicting with package B
 
Hi,

On Thu, Sep 13, 2012 at 04:26:03PM -0700, Russ Allbery wrote:
> None of this language has, as yet, been updated for multiarch, but I
> think it makes logical sense for a M-A: same package to be
> coinstallable even if it Conflicts with its own package name or a
> virtual package it Provides, by extension from the intention of this
> construct without multiarch.

I implemented this exception to a package's conflicts in dose3 and
attached the patch. I therefor also sent this email to Pietro Abate.

I also sent it to bug#685171 because it fixes the regression introduced
by a fix for it.

Dose3 behaviour for cross compilation (which often requires
co-installation of linux-libc-dev) is now again the same as apt.

Thanks for your clarifications!

cheers, josch


--
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/20120914092930.GA3608@hoothoot

Johannes Schauer 09-14-2012 10:20 AM

M-A: Same package A providing and conflicting with package B
 
Hi,

On Fri, Sep 14, 2012 at 11:29:30AM +0200, Johannes Schauer wrote:
> I implemented this exception to a package's conflicts in dose3 and
> attached the patch.

At least planned to... Patch is attached now, sorry.

cheers, josch

Stefano Zacchiroli 09-14-2012 03:11 PM

M-A: Same package A providing and conflicting with package B
 
Johannes: thanks for raising this issue here. Following yours and
Pietro's experiments I was about to post something along the same lines,
but you relieved me of that duty: thanks :-)

On Thu, Sep 13, 2012 at 04:26:03PM -0700, Russ Allbery wrote:
> > That does sound like a bug. The intuitive behavior when foo both
> > Provides and Conflicts with bar would be for the Conflicts to only
> > apply to other packages.
> Indeed. This particular combination of package metadata has a specific
> meaning defined in Policy 7.4:
[…]
> their own package name, or with a virtual package which they provide
> (see below): this does not prevent their installation, and allows a
> package to conflict with others providing a replacement for it. You
> use this feature when you want the package in question to be the only
> package providing some feature.
>
> So you need to specifically recognize the case of Conflicts naming the
> package itself or a virtual package that this package provides, and in
> that case the Conflicts should not be applied to that package for
> installability determination.
>
> None of this language has, as yet, been updated for multiarch, but I think
> it makes logical sense for a M-A: same package to be coinstallable even if
> it Conflicts with its own package name or a virtual package it Provides,
> by extension from the intention of this construct without multiarch.

Russ, thanks for clarifying the status of policy wording wrt multiarch.
I was well aware of Policy 7.4, but it wasn't clear to me whether
updating it wrt multiarch has (supposedly) already happened or not. Do
you want a bug report against policy about this? I did check the bug
listing, but I haven't found anything relevant to this specific issue (I
might have missed more generic multiarch bugs, though).

But still, I could use double checking about the correctness of current
APT's behavior. From how Russ put it above, it shouldn't matter whether
the conflict is via a virtual package name or via a real package name:
self-conflicts across architecture boundaries should be ignored for M-A:
same packages.

According to the attached tests (which are courtesy of Pietro Abate), it
seems that APT does ignore self-conflict across arch boundaries when
they are via virtual packages (test 1), but it doesn't ignore them when
they are via real packages (test 2).


Looking on a random "desktop-like" laptop machine with various suites,
we've found ~200 packages which declare self-conflicts on their real
names (probably due to historical package renaming, that have remained
around). None of them is M-A: same, so the above alleged APT issue is
only theoretical at this point. But it might become real with the
increasing popularity of multiarch-ed packages in the Debian archive.


If you could review the above and confirm it's an APT issue, I'll be
happy to file a bug report (but I can't promise a patch :-P).

TIA,
Cheers.
--
Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
Packages
========

Package: a1
Version: 1
Architecture: arch1
Multi-Arch: same
Provides: ap
Conflicts: ap

Package: a1
Version: 1
Architecture: arch2
Multi-Arch: same
Provides: ap
Conflicts: ap

Package: a2
Version: 1
Architecture: arch1
Multi-Arch: same
Conflicts: a2

Package: a2
Version: 1
Architecture: arch2
Multi-Arch: same
Conflicts: a2

Package: a3
Version: 1
Architecture: arch1
Multi-Arch: same

Package: a3
Version: 1
Architecture: arch2
Multi-Arch: same


Test 1
======

$./fakeapt.sh test install a1:arch1 a1:arch2
[...]
The following NEW packages will be installed:
a1 a1:arch2
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Inst a1 (1 localhost [arch1])
Inst a1:arch2 (1 localhost [arch2])
Conf a1 (1 localhost [arch1])
Conf a1:arch2 (1 localhost [arch2])


Test 2
======

$./fakeapt.sh test install a2:arch1 a2:arch2
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
a2 : Conflicts: a2:arch2 but 1 is to be installed
a2:arch2 : Conflicts: a2 but 1 is to be installed
E: Unable to correct problems, you have held broken packages.


Test 3
======

$./fakeapt.sh test install a3:arch1 a3:arch2
[...]
The following NEW packages will be installed:
a3 a3:arch2
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Inst a3 (1 localhost [arch1])
Inst a3:arch2 (1 localhost [arch2])
Conf a3 (1 localhost [arch1])
Conf a3:arch2 (1 localhost [arch2])

Russ Allbery 09-16-2012 10:22 PM

M-A: Same package A providing and conflicting with package B
 
Stefano Zacchiroli <zack@debian.org> writes:

> Russ, thanks for clarifying the status of policy wording wrt multiarch.
> I was well aware of Policy 7.4, but it wasn't clear to me whether
> updating it wrt multiarch has (supposedly) already happened or not. Do
> you want a bug report against policy about this? I did check the bug
> listing, but I haven't found anything relevant to this specific issue (I
> might have missed more generic multiarch bugs, though).

There has as yet been no work on Policy updates for multiarch. I'm hoping
to be able to start working on that soon. I don't think there's a general
bug for all Policy multiarch support (I should probably add one), just
some more specific ones around the edges:

#621050 Document dependencies needed to use multiarch paths
#636383 10.2 and others: private libraries may also be multi-arch-ified
#650974 Make Policy references to /usr/lib multiarch-aware
#684672 document multiarch tuple definitions

> But still, I could use double checking about the correctness of current
> APT's behavior. From how Russ put it above, it shouldn't matter whether
> the conflict is via a virtual package name or via a real package name:
> self-conflicts across architecture boundaries should be ignored for M-A:
> same packages.

Yes, that's what I think would be a reasonable extension of the current
language around how Conflicts works.

If a package is explicitly tagged Multi-Arch: same, then to me that
clearly implies that the maintainer thinks that multiple architectures of
the package should be installable at the same time. Otherwise, the
package would be tagged Multi-Arch: foreign or not be labelled for
multiarch at all. If Conflicts prevents that, then the combination of a
Conflicts on the package name and Multi-Arch: same would be a straight
bug, since they would contradict each other. If we treat Conflicts on the
package name the same as for a virtual package, then that combination
becomes meaningful: it means that the package itself is co-installable,
but can't be co-installed with any other package that Provides the same
name. That seems more useful.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pq5lobfi.fsf@windlord.stanford.edu">http://lists.debian.org/87pq5lobfi.fsf@windlord.stanford.edu

Guillem Jover 10-06-2012 12:50 AM

M-A: Same package A providing and conflicting with package B
 
Hi!

On Thu, 2012-09-13 at 23:22:40 +0200, Johannes Schauer wrote:
> The dilemma is solved by having all packages A that provide as well as
> conflict with a package B and are also M-A: Same only conflict with B of
> their own architecture and NOT all architectures.
>
> This conclusion doesnt seem obvious to me and I didnt find it written
> down somewhere.
>
> So my question: is the following conclusion correct
>
> > If a package A:$arch conflicts with a package B, then A:$arch
> > conflicts with package B in all architectures EXCEPT if A is M-A: Same
> > AND A also provides B. In this case, A:$arch only conflicts with
> > B:$arch and NOT with B in all its architectures as it would be the
> > default.
>
> And if it is correct, should it be written down somewhere?
>
> Also, if it is correct, is there a more general rule?
>
> And are there more rules that are similar to this one?
>
> This rule is for Provides but what about Replaces?

While I guess in this specific case this might end up being correct,
I don't think it's what was really meant. I'll describe what dpkg
(supposedly) implements, which should match with what we discussed
while drafting the multiarch specification, I'm not sure how apt
implements this though.

Dependency relationships w/o an arch qualifier apply by default to
only the same architecture as the package declaring them, except
for Conflicts/Breaks/Replaces which by default apply to arch:any.

So, for examples:

Package: a
Architecture: arch-a
Depends: d, e:any
Conflict: b, c:arch-d

would become, a:arch-a depends d:arch-a and e:any, conflicts
b:any and c:arch-d. Or a more complex one:

Package: w
Architecture: arch-w
Provides: x:arch-z

Package: z
Architecture: arch-z
Depends: x


About virtual packages, you should think about them either like
pointers to real packages or like a new package instance generated
per providing package. So given this, the architecture of a virtual
package is (almost) always the one of the package providing it (if
it was not arch-qualified of course).

The only “exception” to all this is for self-provides, which extends
the current semantics to treat a package set (a package sharing the
same name) to allow them to be co-installed in case of M-A:same. Which
is nothing more than adapting the current semantics to the general
multiarch semantics.

(There's a bug in dpkg which has allowed more lax handling of virtual
packages and M-A:same relationships on remove and configure up to now,
but I've fixed that and will be included in 1.16.9. And while code
staring I've also found that arch-qualified dependecy relationships
are broken on some conditions, which I've started fixing locally.)

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121006005038.GA30126@gaara.hadrons.org">http://lists.debian.org/20121006005038.GA30126@gaara.hadrons.org


All times are GMT. The time now is 01:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.