Couldn't find any of you on IRC, so I'm filing this bug. The || (any-of) qt dependencies used by qt3.eclass have a flaw. Don't know if you use the same syntax in other places, like kde* eclasses. Considering this: || ( =x11-libs/qt-3.3.4-r6 =x11-libs/qt-3.3.4-r5 =x11-libs/qt-3.3.4-r4 ) If you have x11-libs/qt-3.3.4-r4 installed portage won't update to -r5 or -r6 even if it's properly keyworded, unless x11-libs/qt is listed in world or there are packages depending on qt in a broader way.
Hmm, not sure what to think about this. How can we get around it. Can this be considered a portage bug? Is it a bug that will provide a problem in the long run? IE, will emerge -u package work to upgrade qt as well in this case?
No, portage won't update qt, unless it's listed in world or other packages depend on qt not using the || syntax from qt3.eclass. It goes like this: If none of the atoms in the || list matches an installed version, portage collapses the list to the first available atom. But if one of the atoms matches an installed version, the complete list is collapsed to that one atom. In your case, using the = atoms, you only match one ebuild and portage has no other ebuilds that can be considered for updates.
IMHO it's not a portage bug. The || operator is like virtuals. Actually, virtuals are implemented by replacing the virtual atom with a || list of the providers. It's an any-of match and not a best-of match.
In some instances, the eclass will expand differently: $(qt_min_version 3.1) == || ( =x11-libs/qt-3.3* =x11-libs/qt-3.2* =x11-libs/qt-3.1* ) Maybe we can make the other expansion cases more portage friendly: $(qt_min_verison 3.2.3-r2) == || ( =x11-libs/qt-3.3* =x11-libs/qt-3.2*) !<x11-libs/qt-3.2.3-r2 I wonder if something like that would work?
That only shifts the problem from locking qt at the revision level to the minor version level, but the same flaw still exists. If 3.2 is installed, but 3.3 isn't, portage won't consider qt for an update from 3.2 to 3.3. And depending on a package and also blocking the same package, or some versions of it may have as a result that users manually have to unmerge and re-emerge packages to get the blockers resolved.
Okay, then I don't have any idea on how to solve this one.
Do you want to only match explicitly marked versions with it? Or what's the purpose of using the || operator?
See our discussion in #97404 and my report of #100235 for the logic behind this.
> If you have x11-libs/qt-3.3.4-r4 installed portage won't update to -r5 or > -r6 even if it's properly keyworded, unless x11-libs/qt is listed in world There's a thing I don't understand, how is this different from the normal portage behavior? Portage does not upgrade dependencies unless using -uD. Anyway, if we really cannot get out of this, there's always the Definitive Solution (tm): using "=x11-libs/qt-3*" in _every_ ebuild depending on Qt3. After all, qt-3.3.3 and qt-3.3.4 are the only qt3 versions in portage, so nothing could go really wrong. For Qt4, we should be able to find some reasonable solution. I know it's just like dropping a nuclear weapon on the problem, but hey...
Well, what *could* go wrong is if a person has qt-3.1 installed and they are going to install some package that needs qt-3.3 - with this dep, qt-3.1 satisfies it.
The problem is that portage won't update even if -uD is used when these types of DEPEND strings are the only ones to occur. I can't see any other way to do it at the moment, however. And I'm definitely one for having the dependency correctness rather workarounds that seem better for most users but worse for a few others. For the current portage, I'd say the current way is probably the best. The next version will definitely support ranged dependencies, which will supercede these DEPENDs altogether. As for how the next version will handle these types of DEPENDs... It should be doable if matches against installed packages only happen against the atom keys rather than inclusive of versions.
In our case, we'll probably survive this as we don't expect many updates to the qt-3 packages anymore, save for some bug fixes. If they become critical, we can always force the eclass to cause the user to upgrade to the latest Qt.
Closing this since it is resolved the best we can for now.
