When a KDE split package is masked, and its version hasn't been bumped because there were no change since the previous version (e.g.: libkpgp-3.5.0), and this package is required by another package, the error message is: ################################################################ Calculating world dependencies - emerge: there are no ebuilds to satisfy "~kde-base/libkpgp-3.5.1". (dependency required by "kde-base/certmanager-3.5.1" [ebuild]) !!! Problem resolving dependencies for kde-base/kdepim-meta !!! Depgraph creation failed. ################################################################ There is no mention to the fact the needed ebuild just as to be unmasked, and people think the needed ebuild really is missing... (see bug #124665 and bug #121915, for example). In my case, when I installed KDE 3.5, I just unmasked every "3.5.0" KDE packages, in my package.keyword files... a few days ago, when I wanted to upgrade to KDE 3.5.1, I replace every "-3.5.0" in my package.keyword file, by "-3.5.1"... the result is that every packages which were not updated since KDE 3.5.0, were remasked, and couldn't satisfy dependencies... The error message, in this case, should be changed to the standard error message when a package needed to satisfy a dependency is masked... More details should also be added to the http://www.gentoo.org/doc/en/kde-split-ebuilds.xml document, in the "Split ebuilds FAQ" section, "Why are some split packages missing the newest ebuild versions?" subsection... Something like: ################################################################ If you want to unmask every KDE ebuilds of a specific version, be sure to also unmask older ebuilds, if they were not updated in the version you want to install... (e.g.: if you want to install "kde-base/certmanager-3.5.1", and it it still masked, be sure to also unmask "kde-base/libkpgp-3.5.0" -if it also is still masked-, as "libkpgp" was not updated since KDE 3.5.0, so there are no "libkpgp-3.5.1" ebuild, and the "libkpgp-3.5.0" will be used to satisfy the dependency). ################################################################
*** Bug 121915 has been marked as a duplicate of this bug. ***
*** Bug 130468 has been marked as a duplicate of this bug. ***
Haven't looked at the guide for a while, but probabaly some more explanations would help. For now adding it here: When adding the split kde ebuilds to a package.* file, use e.g. kde-base/<foo> or <=kde-base/<foo>-3.5.2-r99 but avoid hardcoding specific ebuild versions/revisions.
*** Bug 134300 has been marked as a duplicate of this bug. ***
*** Bug 130662 has been marked as a duplicate of this bug. ***
*** Bug 127933 has been marked as a duplicate of this bug. ***
*** Bug 126911 has been marked as a duplicate of this bug. ***
*** Bug 124665 has been marked as a duplicate of this bug. ***
*** Bug 112709 has been marked as a duplicate of this bug. ***
*** Bug 112513 has been marked as a duplicate of this bug. ***
*** Bug 110433 has been marked as a duplicate of this bug. ***
*** Bug 109818 has been marked as a duplicate of this bug. ***
*** Bug 132998 has been marked as a duplicate of this bug. ***
So... now that we have most of the dupes here - can we finally document this stupid message in the split ebuilds howto? ;)
Jakub, please do us the favor not to reopen old bugs to dupe them. Thanks for the bug spam.
*** Bug 134408 has been marked as a duplicate of this bug. ***
*** Bug 135777 has been marked as a duplicate of this bug. ***
*** Bug 135776 has been marked as a duplicate of this bug. ***
*** Bug 136613 has been marked as a duplicate of this bug. ***
*** Bug 180752 has been marked as a duplicate of this bug. ***
*** Bug 181245 has been marked as a duplicate of this bug. ***
*** Bug 181295 has been marked as a duplicate of this bug. ***
It sounds like the original reporter was trying to merge ~arch or hardmasked packages, which we don't encourage in our docs. It's up to the user to properly add every ~arch or hard-masked dependency themselves to package.* files....am I understanding this correctly? If so, then there's nothing for the GDP to add. Or does the KDE team routinely mask older version numbers but without fixing dependencies? (I doubt this is the case, but I guess I don't really know.)
(In reply to comment #23) > It sounds like the original reporter was trying to merge ~arch or hardmasked > packages, which we don't encourage in our docs. It's up to the user to > properly add every ~arch or hard-masked dependency themselves to package.* > files....am I understanding this correctly? If so, then there's nothing for > the GDP to add. > > Or does the KDE team routinely mask older version numbers but without fixing > dependencies? (I doubt this is the case, but I guess I don't really know.) > They do not. If the user do not use ~arch or hardmasked packages, there is no problem. However, while this might not be encouraged, the current behaviour is counterintuitive, and, as such, should be better documented (at least when trying to emerge the ebuilds, but it probably would help some users, if it was also documented in the KDE split ebuilds howto). The problem, as described in the original report, is that, when, for example: - the user want to install kde-meta-3.5.1; - libkpgp-3.5.0 is masked; - libkpgp-3.5.1 ebuild does not exist (because there was not change, since kde-meta-3.5.0); - some ebuild depend on libkgpg-3.5.0 (using the `deprange` function)... ... the user will generally unmask all ~kde-base/*-3.5.1 ebuilds (a script to do this, should probably be documented, for the users who do not know how to automatize this, but this is not the purpose of this report). The problem is, when he will try to emerge the package depending on libkpgp-3.5.0, instead of the usual error message, listing the ebuilds, which are masked, but would satisfy the dependency, if unmasked, the user will get a message telling him there are no ebuilds to satisfy "~kde-base/libkpgp-3.5.1"... and there sure are not, because libkpgp-3.5.1 does not exist. To solve this, use user has to unmask libkpgp-3.5.0, and to find this solution, he either has to unmask all masked libkpgp packages (and all other KDE packages, because the problem will repeat itself), "to try if this works", or open the ebuild depending on libkpgp, to try to understand what is going on inside... ... or report the "missing ebuild" problem (if he cannot find a duplicate), because `emerge` is telling him that the ebuild is missing :) Instead, as said in the original report, `emerge` should properly list the ebuilds which could satisfy the original dependency (I guess the problem comes from using `deprange`, to defines {R,}DEPEND atoms), and there should be some documentation, in the KDE split ebuilds howto, to tell the user, who want to use masked ebuilds of KDE, that he might have to unmask previous versions too, if he get a missing dependency problem (well, if the `emerge` error message listed the ebuilds which need to be unmasked, there is probably no need to add anything more than something like "Note that, because of this, if you want to install masked versions of KDE, you might also need to unmask the previous versions of KDE, if they are also masked.", at the end of the "Why are some split packages missing the newest ebuild versions?" section).
(In reply to comment #24) > If the user do not use ~arch or hardmasked packages, there is no > problem. Good to know.
*** Bug 184171 has been marked as a duplicate of this bug. ***
*** Bug 185034 has been marked as a duplicate of this bug. ***
If the user chooses to use the stable branch or the testing branch there will not be an issue. If packages are selectively unmasked then the error message given by portage can be misleading. Whilst we don't encourage this it couldn't hurt to add a short note about the behaviour. Something like, Please note: whilst we do not encourage mixing ~arch packages with stable packages if some dependencies are missed then the error message indicates the dependency is missing. This is nut the case, it is simply a lower version number. Simply unmask that dependency too, i.e. kde-base/foo.
I've fixed this by adding a note to the document.
