[gentoo-user] Once again baffled by portage

[gentoo-user] Once again baffled by portage

[Grant Edwards]

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
kde<anything> in /etc/portage/*.

   # 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            

-- 
gentoo-user@lists.gentoo.org mailing list

[gentoo-user] Re: Once again baffled by portage

[Michael Schmarck]

· Grant Edwards <grante@visi.com>:

> Why won't portage let me install kompare?

Because you already have it.

>    # 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?

By having a look in the ebuilds.

> There are no other versions of kompare installed.
> kde-base/kdesdk-3.5.7 _is_ installed.  There is no mention of
> kde<anything> in /etc/portage/*.

I suppose kompare is part of kdesdk. kdesdk is a huge package containing
lots of stuff. So I suppose you cannot have both kdesdk and a broken
out package (kompare) installed at the same time.

>    *  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

Yep. There it says: kdesdk also offers Kompare.

Hm, why would you want to install Kompare, if you already have it
installed? 

Michael Schmarck
-- 
Why would anyone want to be called "Later"?


-- 
gentoo-user@lists.gentoo.org mailing list

[gentoo-user] Re: Once again baffled by portage

[Guilherme Amadio]

On Thu, Jan 17, 2008 at 03:28:24PM +0000, Grant Edwards wrote:
> Why won't portage let me install kompare?

>    *  kde-base/kdesdk
>          Description:   KDE SDK: Cervisia, KBabel, KCachegrind, Kompare, Umbrello,...
> 

  By what I understand, kdesdk already includes kompare, that is why it is
  blocking it. If you don't have kompare already, there may be some bug in
  an eclass or ebuild relating to one of these packages. I'm not a kde user,
  but a quick look at the ebuild for kompare showed that the src is the same
  as kdesdk.

  As for where the blocks come from, I think it's directly from the dependencies
  specified in the ebuilds.

  Well, hope that helps.
  
  Cheers,
  Guilherme
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Once again baffled by portage

[Alan McKinnon]

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
> kde<anything> 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

[gentoo-user] Re: Once again baffled by portage

[Grant Edwards]

On 2008-01-17, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 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
>> kde<anything> in /etc/portage/*.
>
> The solution is a little more complex than in Michael's reply and this 
> may take a while :-)

[...]

> 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.

Sure, it makes sense now. :) 

Thanks for the explanation.

-- 
Grant Edwards                   grante             Yow! I was making donuts
                                  at               and now I'm on a bus!
                               visi.com            

-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Once again baffled by portage

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: Once again baffled by portage

[Alan McKinnon]

On Thursday 17 January 2008, Grant Edwards wrote:
> On 2008-01-17, Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> > 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.
>
> Sure, it makes sense now. :)
>
> Thanks for the explanation.

I just re-read my own post and I'm left with one impression:

There gotta be an easier way to do this split-ebuild thing where the 
user can see at a glance if a package is monolithic or not...


-- 
Alan McKinnon
alan dot mckinnon at gmail dot com
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Once again baffled by portage

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Once again baffled by portage

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Once again baffled by portage

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Once again baffled by portage

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

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!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Once again baffled by portage

[Alan McKinnon]

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

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]