Summary: | qt-*-4.5.0_rc1 ebuilds should either block <=qt-4.4.* stuff or there should also be a qt-4.5.0_rc1 meta ebuild | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 |
Component: | [OLD] Unspecified | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caccadura, jeff, Martin.vGagern |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
QT blocks while trying to emerge -NDuav world.
Full results of emerge -uDNavt world |
Description
f5d8fd51ed1e804c9e8d0357e8614e0493b06e96
2009-02-12 10:50:08 UTC
I just checked the qt-core-4.5.0_rc1 ebuild and it just blocks !<x11-libs/qt-4.4.0:4" whilest things were colliding with x11-libs/qt-4.4.2 for me. How exactly do you upgrade? I have TONS!!! of blockers (or so it seems). I simply issued an emerge with all the updated qt-*-4.5.0_rc1 stuff (so no -uD world in this case). Unmerging qt-4.4.2 (the meta ebuild) should also have done the trick. Yes. Everydody should remove qt-4.4.2 meta ebuild and move towards split ebuilds. You wont have any problems after that. We dropped support for the x11-libs/qt:4 meta ebuild. You should only get blockers now if you specifically emerge the qt-4.4.2 meta ebuild before, or have x11-libs/qt without slot designation in your world file. # grep x11-libs/qt /var/lib/portage/world This command should not return any pure "x11-libs/qt". If it does then do: # emerge -C x11-libs/qt:4 and edit /var/lib/portage/world to say x11-libs/qt:3 if you have a Qt3 version installed. After that the upgrade should be smooth. *** Bug 258716 has been marked as a duplicate of this bug. *** Wouldn't it make sense to provide a last qt meta package to help transition? That package could use ewarn to ask admins to unmerge it, and it could either depend on no packages at all (to simulate what happens if you remove the meta) or on the split qt-* packages with no version restriction (to simulate what happens when you emerge split packages instead). With such a meta package in place, admins could upgrade without having to deal with a ton of blockers, and they could get a hint as to what's going on without searching for a bug report. (In reply to comment #7) > Wouldn't it make sense to provide a last qt meta package to help transition? It's does not only make sense, but is essential. It's entirely unacceptable forcing users to mess with the world file manually. It's Portage job to deal with legacy entries and add/remove slotted entries transparently I'll check later, if there is a Portage bug regarding improvement of the world file handling already. (In reply to comment #8) > (In reply to comment #7) > > Wouldn't it make sense to provide a last qt meta package to help transition? > > It's does not only make sense, but is essential. It's entirely unacceptable > forcing users to mess with the world file manually. It's Portage job to deal > with legacy entries and add/remove slotted entries transparently I'll check > later, if there is a Portage bug regarding improvement of the world file > handling already. > Normal users should not have x11-libs/qt on world file at all cause it is always a dependency. You will never need to emerge qt manually. Ever program that requires it , it pulls it a dependency. I ve done this discussion again and again. The solution for those blockages is quite simple. *** Bug 258872 has been marked as a duplicate of this bug. *** (In reply to comment #9) > Normal users should not have x11-libs/qt on world file at all cause it is > always a dependency. Some people might actually try to develop things for qt, or compile third party packages not in portage against it. Others might have forgotten a -1 in some package-specific remerge, e.g. for qt3support. > I ve done this discussion again and again. Point us to a record of it, or repeat it one more time. What is your argument against a transition package? > The solution for those blockages is quite simple. While the solution might be simple for some, finding it is not, as two dups in 36 hours indicate. As an alternative to a transition package, you might consider package-masking the qt:4 ebuild, as you argue that it shouldn't be installed anywhere in any case. That way, you could at least attach a comment to the mask, pointing to this bug here. I see no benefit over a transition package, though. Metapackage is pulling useless dependencies for packags that dont actually need them Let me give you an example lets assume app-misc/foo . This package needs only qt-gui support Having it depend only on qt:4 should pull qt-opengl , qt-sql, qt-svg etc. You see any point this is? Each package should pull the actual dependencies that it needs. Not a bunch of them :) If you are a developer I can provide you a set. But normal users are not developers and they dont need all qt-modules. Did I answer your question? I liked your proposal about masking qt:4 metapackage though (In reply to comment #12) > Metapackage is pulling useless dependencies for packags that dont actually > need them > > Did I answer your question? That's a strong argument against any packages depending on the meta package, but none against the meta package itself. Qt meta ebuild for 4.5.0_rc1 committed. But I dropped arch keywords for those arches that don't have qt-webkit keyworded. (In reply to comment #14) > Qt meta ebuild for 4.5.0_rc1 committed. But I dropped arch keywords for those > arches that don't have qt-webkit keyworded. > I'm still lost. I tried emerge -C x11-libs/qt:4 but afterwards, grep x11-libs/qt /var/lib/portage/world returns x11-libs/qt x11-libs/qt-svg x11-libs/qt-webkit x11-libs/qt:3 What am I supposed to do to fix this allegedly 'solved' bug? Your output seems broken. There is no way to have x11-libs/qt in your word file if you have done emerge -C x11-libs/qt:4 Apart from that, what is wrong anyway? Cant you ugrade your qt packages? Created attachment 190004 [details]
QT blocks while trying to emerge -NDuav world.
(In reply to comment #16) > Your output seems broken. There is no way to have x11-libs/qt in your word file > if you have done emerge -C x11-libs/qt:4 > > Apart from that, what is wrong anyway? Cant you ugrade your qt packages? > Evidently, there is a way. Here's a snapshot from my reattempt localhost ~ # grep x11-libs/qt /var/lib/portage/world x11-libs/qt x11-libs/qt-svg x11-libs/qt-webkit x11-libs/qt:3 localhost ~ # emerge -C x11-libs/qt:4 --- Couldn't find 'x11-libs/qt:4' to unmerge. >>> No packages selected for removal by unmerge localhost ~ # grep x11-libs/qt /var/lib/portage/world x11-libs/qt x11-libs/qt-svg x11-libs/qt-webkit x11-libs/qt:3 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ] x11-libs/qt-4.5.0 [3.3.8b-r1] USE="dbus opengl qt3support" 0 kB Total: 1 package (1 in new slot), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] y >>> Verifying ebuild manifests >>> Emerging (1 of 1) x11-libs/qt-4.5.0 * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... >>> Source unpacked in /var/tmp/portage/x11-libs/qt-4.5.0/work >>> Configuring source in /var/tmp/portage/x11-libs/qt-4.5.0/work ... >>> Source configured. >>> Compiling source in /var/tmp/portage/x11-libs/qt-4.5.0/work ... >>> Source compiled. >>> Test phase [not enabled]: x11-libs/qt-4.5.0 >>> Install qt-4.5.0 into /var/tmp/portage/x11-libs/qt-4.5.0/image/ category x11-libs >>> Completed installing qt-4.5.0 into /var/tmp/portage/x11-libs/qt-4.5.0/image/ >>> Installing x11-libs/qt-4.5.0 * checking 0 files for package collisions * Please note that this meta package is only provided for convenience. * No packages should depend directly on this meta package, but on the * specific split Qt packages needed. This ebuild will be removed in * future versions. Users that want all Qt components installed are * advised to use the set currently available in qting-edge overlay. * Messages for package x11-libs/qt-4.5.0: * Please note that this meta package is only provided for convenience. * No packages should depend directly on this meta package, but on the * specific split Qt packages needed. This ebuild will be removed in * future versions. Users that want all Qt components installed are * advised to use the set currently available in qting-edge overlay. >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date I've also attached the results of my attempt to do an emerge -NDuav world, showing all the qt related blocks that I'm getting Jeff Apparently you dont have keyworded all the qt modules Please check your package.keywords again or provide us a full emerge -uDNavt world output Created attachment 190008 [details] Full results of emerge -uDNavt world Attached at file blocks2.txt. Here's the relevant section of package.keywords # --- # BEGIN: x11-libs/qt-4.5.0 # --- =x11-libs/qt-4.5.0 ~x86 =x11-libs/qt-dbus-4.5.0 ~x86 =x11-libs/qt-sql-4.5.0 ~x86 =x11-libs/qt-webkit-4.5.0 ~x86 =x11-libs/qt-svg-4.5.0 ~x86 =x11-libs/qt-script-4.5.0 ~x86 =x11-libs/qt-gui-4.5.0 ~x86 =x11-libs/qt-core-4.5.0 ~x86 =x11-libs/qt-assistant-4.5.0 ~x86 =x11-libs/qt-qt3support-4.5.0 ~x86 =x11-libs/qt-xmlpatterns-4.5.0 ~x86 =x11-libs/qt-opengl-4.5.0 ~x86 =x11-libs/qt-test-4.5.0 ~x86 # --- # END: x11-libs/qt-4.5.0 # --- (In reply to comment #19) > Apparently you dont have keyworded all the qt modules > Please check your package.keywords again or provide us a full emerge -uDNavt > world output > Upgrade your smplayer to any version > 0.6.6 Smplayer-0.6.6 requires Qt-4.4.2 but any other version works with >Qt-4.4.2 That's what you get for mixing stable and testing branches... (In reply to comment #22) > That's what you get for mixing stable and testing branches... > Sarcastic, and totally unhelpful :-/ (In reply to comment #21) > Upgrade your smplayer to any version > 0.6.6 > > Smplayer-0.6.6 requires Qt-4.4.2 but any other version works with >Qt-4.4.2 > I tried unmerging smplayer (since I don't really need it, and all versions greater than 0.6.6 appear to be masked, prelimimary versions). Portage still claims 1 block, but it is no longer one that stops the updates. Thanks for the helpful advice. Jeff (In reply to comment #23) > (In reply to comment #22) > > That's what you get for mixing stable and testing branches... > > > Sarcastic, and totally unhelpful :-/ > Is it? You should be prepared to have such issues if you are using both stable and unstable packages. Either use the stable branch or move to unstable. But if you mix them , dont complain that something is broken :) (In reply to comment #25) > > > That's what you get for mixing stable and testing branches... > > > > > Sarcastic, and totally unhelpful :-/ > > > > Is it? You should be prepared to have such issues if you are using both stable > and unstable packages. Either use the stable branch or move to unstable. But if > you mix them , dont complain that something is broken :) > Yes - totally unhelpful. Markos very accurately identified the problem package, and pointed out a way to fix it. In response to his advice, I removed smplayer, and everything worked. His advice had value, and allowed me to resolve the problem. Your comment could basically be paraphrased as "I know more than you, I know what you're doing wrong, but I'm just going to give out a smartarse comment instead of helping you fix it". (In reply to comment #26) > (In reply to comment #25) > > > > > That's what you get for mixing stable and testing branches... > > > > > > > Sarcastic, and totally unhelpful :-/ > > > > > > > Is it? You should be prepared to have such issues if you are using both stable > > and unstable packages. Either use the stable branch or move to unstable. But if > > you mix them , dont complain that something is broken :) > > > Yes - totally unhelpful. > > Markos very accurately identified the problem package, and pointed out a way to > fix it. In response to his advice, I removed smplayer, and everything worked. > His advice had value, and allowed me to resolve the problem. > > Your comment could basically be paraphrased as "I know more than you, I know > what you're doing wrong, but I'm just going to give out a smartarse comment > instead of helping you fix it". > Sorry - didn't realise this one came from you Markos, not the original poster of the comment. The reply still stands, directed at the original poster though. If there is a basic issue with how I'm operating my system, I'd like to know the information to fix it, but just to post 'yeah, you're doing something daft' with no information that I can use, is not helpful. Jeff Hehe no problem. All I am saying is that you should not use a mixed system with both stable and unstable packages cause you usually encounter several problems ( just like this one ). Either use a complete unstable system or a full stable one. But of course you can use a mixed one if you know how to fix blockages etc. If you want to move to a complete unstable system you can add ACCEPT_KEYWORDS="amd64 ~amd64" on your /etc/make.conf ( that is for an amd64 system ) or ACCEPT_KEYWORDS="x86 ~x86" for a x86 system. Also note that unstable system might have some broken packages ( this is why we call it "unstable" ) |