Bugzilla Bug 68220

heimdal and mit-krb5 both provide virtual/krb5, and block virtual/krb5, like
they should. mit-krb5 is the default virtual.
It's quite possible to have both installed at the same time though.

USE=kerberos emerge heimdal openssh

heimdal will install, then openssh will pull in virtual/krb5, but it'll take
mit-krb5 as at dependancy resolution nothing satisfied the virtual.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.



Expected Results:

Ahh, I see what you are saying. It's fixed in >=portage-2.0.51_rc1. The order
matters though. If you specify "USE=kerberos emerge heimdal openssh" it'll do
what you want here. If you specify "USE=kerberos emerge openssh heimdal" it'll
fail telling you that the packages block each other.

OK, I get what you say about the how ordering matters, but it's not really
fixed :)

kylie root # emerge portage -p

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] sys-apps/portage-2.0.51_rc9

kylie root # USE=kerberos emerge heimdal openssh -p

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] app-crypt/heimdal-0.6.3-r1
[ebuild  N    ] app-crypt/mit-krb5-1.3.4
[ebuild   R   ] net-misc/openssh-3.8.1_p1-r1

kylie root # USE=kerberos emerge openssh heimdal -p

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[blocks B     ] app-crypt/mit-krb5 (from pkg app-crypt/heimdal-0.6.3-r1)
[ebuild  N    ] app-crypt/mit-krb5-1.3.4
[ebuild   R   ] net-misc/openssh-3.8.1_p1-r1
[ebuild  N    ] app-crypt/heimdal-0.6.3-r1

In this case, I specified heimdal first because I wanted that, and not
mit-krb5. But portage will happily install both.

I'll try to get this fixed on the weekend.

Found and fixed. Will be in 2.0.51-r3.

The problem occured only with virtuals and only if the first package is not the default virtual and was due to the dep_virtual function not using the same record of virtuals as the dep grapher.

Thanks Jason.

I'm just installing another box, and am seeing another issue, which is in a similar vain to this bug.

wwwproxy root # emerge heimdal -pv

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[blocks B     ] app-crypt/mit-krb5 (from pkg app-crypt/heimdal-0.6.3-r1)
[ebuild  N    ] net-libs/openslp-1.0.11  0 kB
[ebuild  N    ] app-crypt/mit-krb5-1.3.4-r1  -krb4 -static 0 kB
[ebuild  NS   ] sys-libs/db-1.85-r1  0 kB
[ebuild  N    ] sys-libs/gdbm-1.8.0-r5  +berkdb -debug -static 0 kB
[ebuild  N    ] dev-libs/cyrus-sasl-2.1.19-r1  -authdaemond +berkdb -debug +gdbm -java +kerberos +ldap -mysql +pam -postgres +ssl -static 1,501 kB
[ebuild  N    ] net-nds/openldap-2.1.30-r2  +berkdb +crypt -debug +gdbm -ipv6 -odbc +perl +readline -samba +sasl +slp +ssl +tcpd 0 kB
[ebuild  N    ] app-crypt/heimdal-0.6.3-r1  +berkdb -ipv6 -krb4 +ldap +ssl 3,255 kB

Total size of downloads: 4,756 kB

heimdal depends on openldap, which depends on virtual/krb5, which as you know defaults to app-crypt/mit-krb5.
Would your fix, "fix" this?

Created an attachment (id=43334) [details]
2.0.52-r2-blocking-virtuals.patch

This is the patch that fixes the first issue. I think it should fix the second
issue as well, but it won't hurt to confirm.

Created an attachment (id=43337) [details]
Emerge output

Cheers Jason, I've whipped out a fresh 2004.2 stage3 tarball in a chroot to
test on. Updated it to portage-2.0.51-r2, and set the kerberos, ldap, and sasl
USE flags.
Was the patch supposed to be just 3 changed lines? Seems kinda small to me :)

Unfortunatly it doesn't fix either issue :(
The second from last emerge appears happy to install both heimdal and mit-krb5.

Created an attachment (id=43346) [details]
2.0.52-r2-blocking-virtuals.patch

I'll take that as a sign that I need to slow down. ;)
This is the full patch.

Much better, thanks.

Not quite perfect yet, but fairly acceptable.
It would be nice if the order in which the packages are specified doesn't matter, but I suspect that's just the way it is. I think you'd be going backwards and forwards over the dependency chain, getting into a right mess.


mahdell / # emerge openssh heimdal -pv

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[blocks B     ] app-crypt/mit-krb5 (from pkg app-crypt/heimdal-0.6.3-r1)
[ebuild  N    ] app-crypt/mit-krb5-1.3.4-r1  -krb4 -static 6,220 kB
[ebuild   R   ] net-misc/openssh-3.8.1_p1-r1  -X509 -chroot -debug -ipv6* +kerberos* +ldap* +pam (-selinux) -skey -smartcard -static +tcpd (-uclibc) 798 kB
[ebuild  NS   ] sys-libs/db-1.85-r1  264 kB
[ebuild  N    ] sys-libs/gdbm-1.8.0-r5  +berkdb -debug -static 130 kB
[ebuild  N    ] dev-libs/cyrus-sasl-2.1.19-r1  -authdaemond +berkdb -debug +gdbm -java +kerberos +ldap -mysql +pam -postgres +ssl -static 1,501 kB
[ebuild  N    ] net-nds/openldap-2.1.30-r2  +berkdb +crypt -debug +gdbm -ipv6 -odbc +perl +readline -samba +sasl -slp +ssl +tcpd 1,996 kB
[ebuild  N    ] app-crypt/heimdal-0.6.3-r1  +berkdb -ipv6 -krb4 +ldap +ssl 3,255 kB

Total size of downloads: 14,167 kB

*** Bug 73157 has been marked as a duplicate of this bug. ***

*** Bug 76197 has been marked as a duplicate of this bug. ***

*** Bug 41497 has been marked as a duplicate of this bug. ***

This bug could be fixed by having portage re-check its dependancies when ANY
virtual gets updated - JUST like when the portage package itself gets updated
:)

Keywords has InCVS and a patch is attached.. This is fixed already. It's just
not in a arch portage yet - it is in the ~arch portage.

Any idea when this bug will be fully fixed, so the order of the packages won't
matter? The user (or, in my case, a system-managment layer above Portage)
really should not need to know anything about the order in which packages need
to be installed. That's what Portages dependancy resolution code is for.  

As I said before, this bug is fixed and will be closed as soon as a portage
later than 2.0.51-r3 is marked stable on all architectures. What you are after
is bug #1343.

Ah, OK, will subscribe to that one then. Thanks!

Fixing this created another bug which is at #79509. I've uploaded a patch there
that fixes that bug. Can people test that there is no regression with regard to
this one, please?

Fixed on or before 2.0.51.22-r1 

Looking through the batch of bugs, I'm not sure that some of these are 
actually fixed in stable. Others, the requirements have possibly changed after 
the initial fix was committed. 
 
If you think this bug has been closed incorrectly, please reopen or ask that 
it be reopened.