| Summary: | blocking virtuals installable at the same time | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Mike Williams <mike> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | David.Huff, martinoc, max, sascha-gentoo-bugzilla |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
2.0.52-r2-blocking-virtuals.patch
Emerge output 2.0.52-r2-blocking-virtuals.patch |
||
|
Description
Mike Williams
2004-10-19 16:52:07 UTC
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 attachment 43334 [details, diff]
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 attachment 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 attachment 43346 [details, diff]
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. |
