Re: [gentoo-user] Once again baffled by portage
On Friday 18 January 2008 15:36:29 Alan McKinnon wrote: Roll on KDE4 when this monolithic nonsense will go away and there will only be -meta ebuilds. Actually it was decided to keep monolithics in KDE 4.0.0. Splits are now the default which means they are listed first in any-of dependency blocks such as e.g. || ( kde-base/kompare:kde-4 kde-base/kdesdk:kde-4 ) in KDE 4. But monos are still around. There is a list of the monos in the url I posted in another mail to this thread. Interesting, I wasn't aware of that. Obviously my most current info is out of date. But why was that decision taken? I understand keeping it for kde-3.5.x users, but kde-4 is essentially an entirely different product, and the -meta ebuilds do everything the monolithic ones ever did. The configure steps do add time though, but other than that everything seems to work the same Well, it wasn't really my decision. ;) But I can say that a pro is that it provides the users with a choice and the maintainance overhead when compared to only doing splits isn't really all that big. The only real con in my opinion is that it confuses those who haven't read the kde-split document before installing kde. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Once again baffled by portage
On Friday 18 January 2008, Bo Ørsted Andresen wrote: On Thursday 17 January 2008 17:06:28 Alan McKinnon wrote: Roll on KDE4 when this monolithic nonsense will go away and there will only be -meta ebuilds. Actually it was decided to keep monolithics in KDE 4.0.0. Splits are now the default which means they are listed first in any-of dependency blocks such as e.g. || ( kde-base/kompare:kde-4 kde-base/kdesdk:kde-4 ) in KDE 4. But monos are still around. There is a list of the monos in the url I posted in another mail to this thread. Interesting, I wasn't aware of that. Obviously my most current info is out of date. But why was that decision taken? I understand keeping it for kde-3.5.x users, but kde-4 is essentially an entirely different product, and the -meta ebuilds do everything the monolithic ones ever did. The configure steps do add time though, but other than that everything seems to work the same -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Once again baffled by portage
On Thursday 17 January 2008, Grant Edwards wrote: Why won't portage let me install kompare? # emerge --pretend kompare These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N] kde-base/kompare-3.5.7 USE=arts -debug -kdeenablefinal -kdehiddenvisibility -xinerama [blocks B ] =kde-base/kompare-3.5* (is blocking kde-base/kdesdk-3.5.7) [blocks B ] =kde-base/kdesdk-3.5* (is blocking kde-base/kompare-3.5.7) How does one figure out where these blocks are coming from? There are no other versions of kompare installed. kde-base/kdesdk-3.5.7 _is_ installed. There is no mention of kdeanything in /etc/portage/*. The solution is a little more complex than in Michael's reply and this may take a while :-) . Normally with blockers one looks in the ebuild to see what you may and may not do, this is often enough info. The contents of /etc/portage/* is seldom useful here as blockers almost always mean you have specified two things that cannot co-exist. In your case, you have run into monolithic and -meta kde ebuilds. Guess what - you already have the kompare binaries, despite the fact that kde-base/kompare is not installed. That's because they are actually part of kdesdk. There are two ways I would have gone about finding this out: a. 'equery depends kompare' would have said that kdesdk-meta depends on it, if it were installed (which it isn't on your machine). b. Looking into the ebuild for kdesdk-meta shows: RDEPEND= ... $(deprange $PV $MAXKDEVER kde-base/kompare) ... So the -meta package installs kompare, therefore the monolithic package will too. Essentially you are trying to install one of the individual packages from a -meta package at the same time as a corresponding monolithic package,and portage is correctly refusing to let you do this. How did I immediately know that this is the cause? School of hard knocks :-) From experience I have a good idea of the name of the 15 or so KDE monolithic packages, and the general rule I follow is that blockers related to kde are usually conflicts between -meta and monolithic ebuilds. Roll on KDE4 when this monolithic nonsense will go away and there will only be -meta ebuilds. alan # emerge --search kompare Searching... [ Results for search key : kompare ] [ Applications found : 1 ] * kde-base/kompare Latest version available: 3.5.7 Latest version installed: [ Not Installed ] Size of files: 5,078 kB Homepage: http://www.kde.org/ Description: KDE: A program to view the differences between files and optionally generate a diff License: GPL-2 # emerge --search '%^kdesdk$' Searching... [ Results for search key : ^kdesdk$ ] [ Applications found : 1 ] * kde-base/kdesdk Latest version available: 3.5.7 Latest version installed: 3.5.7 Size of files: 5,088 kB Homepage: http://www.kde.org/ Description: KDE SDK: Cervisia, KBabel, KCachegrind, Kompare, Umbrello,... License: GPL-2 -- Grant Edwards grante Yow! Am I in Milwaukee? at visi.com -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Once again baffled by portage
On Thursday 17 January 2008 16:28:24 Grant Edwards wrote: How does one figure out where these blocks are coming from? There are no other versions of kompare installed. kde-base/kdesdk-3.5.7 _is_ installed. http://www.gentoo.org/doc/en/kde-split-ebuilds.xml -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Once again baffled by portage
On Thursday 17 January 2008 17:06:28 Alan McKinnon wrote: Roll on KDE4 when this monolithic nonsense will go away and there will only be -meta ebuilds. Actually it was decided to keep monolithics in KDE 4.0.0. Splits are now the default which means they are listed first in any-of dependency blocks such as e.g. || ( kde-base/kompare:kde-4 kde-base/kdesdk:kde-4 ) in KDE 4. But monos are still around. There is a list of the monos in the url I posted in another mail to this thread. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Once again baffled by portage
On Fri, 18 Jan 2008 00:41:04 +0100, Bo Ørsted Andresen wrote: Actually it was decided to keep monolithics in KDE 4.0.0. Splits are now the default which means they are listed first in any-of dependency blocks such as e.g. || ( kde-base/kompare:kde-4 kde-base/kdesdk:kde-4 ) in KDE 4. But monos are still around. There is a list of the monos in the url I posted in another mail to this thread. Would it be possible to modify the kde-meta eclass so that a split vs monolithic block gave a more informative error message. Even a generic message pointing to that URI would be a great help. -- Neil Bothwick Daisy Duke shorts would never go out of fashion. signature.asc Description: PGP signature
Re: [gentoo-user] Once again baffled by portage
On Friday 18 January 2008 01:08:51 Neil Bothwick wrote: Actually it was decided to keep monolithics in KDE 4.0.0. Splits are now the default which means they are listed first in any-of dependency blocks such as e.g. || ( kde-base/kompare:kde-4 kde-base/kdesdk:kde-4 ) in KDE 4. But monos are still around. There is a list of the monos in the url I posted in another mail to this thread. Would it be possible to modify the kde-meta eclass so that a split vs monolithic block gave a more informative error message. Even a generic message pointing to that URI would be a great help. Since we only have the RDEPEND=!kde-base/kdesdk:kde-4 etc. dependency syntax which doesn't allow messages I don't see how (if you see a possibility I'm missing say so). The message you get is a generic resolver failure. If you have ideas for better wording of the blocker message from portage I guess you should file a portage bug. If you have any ideas for extending the ebuild format to make it possible to add custom messages with urls then I guess filing a PMS/EAPI bug is the way to go. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Once again baffled by portage
On Fri, 18 Jan 2008 01:17:18 +0100, Bo Ørsted Andresen wrote: Would it be possible to modify the kde-meta eclass so that a split vs monolithic block gave a more informative error message. Even a generic message pointing to that URI would be a great help. Since we only have the RDEPEND=!kde-base/kdesdk:kde-4 etc. dependency syntax which doesn't allow messages I don't see how (if you see a possibility I'm missing say so). I don't, I was merely asking if it was possible. I take it your answer is a no :( -- Neil Bothwick Access denied--nah nah na nah nah! signature.asc Description: PGP signature
