I have emerged kdevelop-3.0.0_beta1 using #ACCEPT_KEYWORDS=~x86 emerge kdevelop Now I have the following output from emerge every time: # emerge -pU world [ebuild N ] dev-util/kdoc-2.0_alpha54 [ebuild N ] app-text/psutils-1.17 [ebuild N ] dev-util/gperf-2.7.2 [ebuild N ] app-text/a2ps-4.13b-r5 [ebuild N ] net-www/htdig-3.1.6-r4 [ebuild N ] app-text/enscript-1.6.3-r1 [ebuild N ] dev-util/kdbg-1.2.9 [ebuild N ] dev-util/kdevelop-2.1.5 Note that all the packages here are N (new). There's no apparent reason for emerge to want them installed. (I'm sorry if this is bad bug report, but http://bugs.gentoo.org/bugwritinghelp.html gives me a 403 Forbidden, so I can't do any better :)
This is an unfortunate aspect of portage - since 3.0.0_beta1 is both ~x86 and masked, your system wants to install the "latest" version which it finds to be 2.1.5. I'm going to reassign to portage and let them decide how to handle the report.
In that case it's covered by package.keywords *** This bug has been marked as a duplicate of 13616 ***
I don't think the resolution is correct. Point #1: when I inject dev-util/kdevelop-2.1.5, Portage wants to install its dependencies (all the other packages I listed) anyway. This is very weird. Point #2: this doesn't happen with other unstable packages. E.g. I emerged ghc-6.0 using ACCEPT_KEYWORDS=~x86. Now I have this (real output from my system): ============================================================== $ emerge -pu world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild UD] dev-libs/gmp-4.1-r1 [4.1.2] [ebuild UD] dev-lang/ghc-5.04.3-r1 [6.0.1] [ebuild UD] dev-haskell/haddock-0.4 [0.5] [ebuild N ] dev-util/kdoc-2.0_alpha54 [ebuild N ] app-text/psutils-1.17 [ebuild N ] dev-util/gperf-2.7.2 [ebuild N ] app-text/a2ps-4.13b-r5 [ebuild N ] net-www/htdig-3.1.6-r4 [ebuild N ] app-text/enscript-1.6.3-r1 [ebuild N ] dev-util/kdbg-1.2.9 [ebuild N ] dev-util/kdevelop-2.1.5 $ emerge -pU world >>> --upgradeonly implies --update... adding --update to options. These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild N ] dev-util/kdoc-2.0_alpha54 [ebuild N ] app-text/psutils-1.17 [ebuild N ] dev-util/gperf-2.7.2 [ebuild N ] app-text/a2ps-4.13b-r5 [ebuild N ] net-www/htdig-3.1.6-r4 [ebuild N ] app-text/enscript-1.6.3-r1 [ebuild N ] dev-util/kdbg-1.2.9 [ebuild N ] dev-util/kdevelop-2.1.5 ==================================================================== Note how the behaviour is different: with ghc, Portage clearly marks ghc-5.04.3-r1 as "upgrade/downgrade" and doesn't attempt to merge it when I use -U. Not so with kdevelop. In my view the behaviour with ghc is reasonable and with kdevelop it's not. There's no apparent reason for this. By the way neither kdevelop nor ghc are listed in /usr/portage/profiles/package.mask
The reason for this behavior is that kdevelop is slotted and ghc isn't. So either it's a dup of 13616 or an unwanted feature in the kdevelop ebuild (= re-assign to kde folks), what do you prefer ?
IMHO this is not a kde folks' problem, they should be able to slot their packages how they wish. OTOH per-package variables would almost solve this problem. Almost, but not quite. I don't want to set ~x86 for a particular package because I don't *always* want the unstable version of that package. I usually want just this one particular unstable version. I want to set USE flags per package, yes, but not necessarily ACCEPT_KEYWORDS. Back to the issue. AFAICT the sequence of events is like this. 1. Portage sees kdevelop in the world file. 2. It checks what is the latest version of it. It's 2.1.4 (3.0 is ~x86 so it's not considered). 3. It determines what slot it is. It's slot 2. 4. It looks at installed versions of kdevelop in slot 2. There are none. 5. Portage wants to install 2.1.4. If this is correct, there is a way to fix this. At step 4, if there's nothing in slot 2, portage should look at slots >2. If there's something there, portage should not attempt to install. Maybe the world file should contain information about slots too. IMHO this is quite different from what 13616 is about. Anyway, I just temporarily commented out kdevelop in my world file, until 3.0 is stable, and the problem went away.
package.keywords also supports settng the keywords for only a specific version, so you could use: =dev-util/kdevelop-3.0.0_beta1 ~x86 to only unmask that version. So bug 13616 would solve this bug. Your proposed "fix" for the SLOT problem isn't one as it would defeat the purpose of SLOTs.
> package.keywords also supports settng the keywords for only a specific version, > so you could use: > =dev-util/kdevelop-3.0.0_beta1 ~x86 > to only unmask that version. So bug 13616 would solve this bug. Agreed here. If you think it should be closed as a dupe of 13616, please go ahead and close it. > Your proposed "fix" for the SLOT problem isn't one as it would defeat the > purpose of SLOTs. Yes, in the case when the package in question is a dependency for some other package, the "fix" is broken. But when it's not a dependency (i.e. explicitly merged), I don't see why not do that. AFAICT SLOTs are there so we can have multiple versions of a package installed, either to satisfy dependencies of other packages, or when the user explicitly requests multiple versions. But neither case is applicable here.
*** Bug 28423 has been marked as a duplicate of this bug. ***
Portage won't install unstable unless you tell it to. use package.keywords.
