Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 258712 - 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
Summary: qt-*-4.5.0_rc1 ebuilds should either block <=qt-4.4.* stuff or there should a...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
: 258716 258872 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-12 10:50 UTC by f5d8fd51ed1e804c9e8d0357e8614e0493b06e96
Modified: 2009-05-04 13:40 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
QT blocks while trying to emerge -NDuav world. (blocks.txt,5.69 KB, text/plain)
2009-04-30 22:12 UTC, Jeff Cranmer
Details
Full results of emerge -uDNavt world (blocks2.txt,31.34 KB, text/plain)
2009-05-01 00:28 UTC, Jeff Cranmer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2009-02-12 10:50:08 UTC
otherwise updating is rather complicated

Reproducible: Always

Steps to Reproduce:
Comment 1 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2009-02-12 10:53:46 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.
Comment 2 Billy DeVincentis 2009-02-12 10:58:53 UTC
How exactly do you upgrade? I have TONS!!! of blockers (or so it seems).
Comment 3 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2009-02-12 11:03:36 UTC
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.
Comment 4 Markos Chandras (RETIRED) gentoo-dev 2009-02-12 11:57:50 UTC
Yes. Everydody should remove qt-4.4.2 meta ebuild and move towards split ebuilds. You wont have any problems after that.
Comment 5 Ben de Groot (RETIRED) gentoo-dev 2009-02-12 14:01:39 UTC
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.
Comment 6 Markos Chandras (RETIRED) gentoo-dev 2009-02-12 14:39:44 UTC
*** Bug 258716 has been marked as a duplicate of this bug. ***
Comment 7 Martin von Gagern 2009-02-13 15:53:03 UTC
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.
Comment 8 Carsten Lohrke (RETIRED) gentoo-dev 2009-02-13 16:17:46 UTC
(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.
Comment 9 Markos Chandras (RETIRED) gentoo-dev 2009-02-13 18:12:50 UTC
(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.


Comment 10 Carsten Lohrke (RETIRED) gentoo-dev 2009-02-13 20:40:57 UTC
*** Bug 258872 has been marked as a duplicate of this bug. ***
Comment 11 Martin von Gagern 2009-02-13 22:08:03 UTC
(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.
Comment 12 Markos Chandras (RETIRED) gentoo-dev 2009-02-13 22:37:48 UTC
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
Comment 13 Martin von Gagern 2009-02-13 22:42:24 UTC
(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.
Comment 14 Ben de Groot (RETIRED) gentoo-dev 2009-02-14 00:42:25 UTC
Qt meta ebuild for 4.5.0_rc1 committed. But I dropped arch keywords for those arches that don't have qt-webkit keyworded.
Comment 15 Jeff Cranmer 2009-04-26 18:03:20 UTC
(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?

Comment 16 Markos Chandras (RETIRED) gentoo-dev 2009-04-26 18:26:53 UTC
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?
Comment 17 Jeff Cranmer 2009-04-30 22:12:38 UTC
Created attachment 190004 [details]
QT blocks while trying to emerge -NDuav world.
Comment 18 Jeff Cranmer 2009-04-30 22:18:32 UTC
(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
Comment 19 Markos Chandras (RETIRED) gentoo-dev 2009-04-30 22:20:47 UTC
Apparently you dont have keyworded all the qt modules
Please check your package.keywords again or provide us a full emerge -uDNavt world output
Comment 20 Jeff Cranmer 2009-05-01 00:28:11 UTC
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
>
Comment 21 Markos Chandras (RETIRED) gentoo-dev 2009-05-01 08:17:06 UTC
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
Comment 22 Ben de Groot (RETIRED) gentoo-dev 2009-05-01 09:55:32 UTC
That's what you get for mixing stable and testing branches...
Comment 23 Jeff Cranmer 2009-05-02 17:50:34 UTC
(In reply to comment #22)
> That's what you get for mixing stable and testing branches...
> 
Sarcastic, and totally unhelpful :-/
Comment 24 Jeff Cranmer 2009-05-02 18:03:53 UTC
(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



Comment 25 Markos Chandras (RETIRED) gentoo-dev 2009-05-02 20:46:54 UTC
(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 :)
Comment 26 Jeff Cranmer 2009-05-03 00:13:27 UTC
(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".
Comment 27 Jeff Cranmer 2009-05-03 00:16:57 UTC
(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


Comment 28 Markos Chandras (RETIRED) gentoo-dev 2009-05-03 02:20:16 UTC
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" )