Yet another problem with the *&^O KDE updates.

[ewbish]

So I sync and go through the same BS as everyone else does earlier this week. I follow all the tips on the multiple threads dealing with this issue and I am left with:

[blocks B ] >=kde-base/kdelibs-3.5.4-r2 (is blocking kde-base/kde-env-3-r4)

The best part is, kdelibs is already removed!!!!


#emerge -c kdelibs-3.5.4-r2

--- Couldn't find 'kdelibs-3.5.4-r2' to clean.

>>> No packages selected for removal by clean.

I've done all the unmerges, resynces, oneshots, blah blah blah, and I'm still left with this. Obviously, somewhere there is a bug that is not recognizing that kdelibs has been removed. Not sure where to go from here. IMHO, somebody sure screwed the pooch on portage this week.

Eric

[someone19]

So I sync and go through the same BS as everyone else does earlier this week. I follow all the tips on the multiple threads dealing with this issue and I am left with:

[blocks B ] >=kde-base/kdelibs-3.5.4-r2 (is blocking kde-base/kde-env-3-r4)

The best part is, kdelibs is already removed!!!!


#emerge -c kdelibs-3.5.4-r2

--- Couldn't find 'kdelibs-3.5.4-r2' to clean.

>>> No packages selected for removal by clean.

I've done all the unmerges, resynces, oneshots, blah blah blah, and I'm still left with this. Obviously, somewhere there is a bug that is not recognizing that kdelibs has been removed. Not sure where to go from here. IMHO, somebody sure screwed the pooch on portage this week.

Eric

Code: Select all

emerge -aC kde-env

[ewbish]

So I sync and go through the same BS as everyone else does earlier this week. I follow all the tips on the multiple threads dealing with this issue and I am left with:

[blocks B ] >=kde-base/kdelibs-3.5.4-r2 (is blocking kde-base/kde-env-3-r4)

The best part is, kdelibs is already removed!!!!


#emerge -c kdelibs-3.5.4-r2

--- Couldn't find 'kdelibs-3.5.4-r2' to clean.

>>> No packages selected for removal by clean.

I've done all the unmerges, resynces, oneshots, blah blah blah, and I'm still left with this. Obviously, somewhere there is a bug that is not recognizing that kdelibs has been removed. Not sure where to go from here. IMHO, somebody sure screwed the pooch on portage this week.

Eric

Code: Select all

emerge -aC kde-env

#emerge -aC kde-env

>>> These are the packages that would be unmerged:

--- Couldn't find 'kde-env' to unmerge.

>>> No packages selected for removal by unmerge.

Of course, that's obvious, as it is being blocked for install.

[MotivatedTea]

#emerge -c kdelibs-3.5.4-r2

--- Couldn't find 'kdelibs-3.5.4-r2' to clean.

First of all, to unmerge, you need a capital C, not a lowercase one. So, try:

Code: Select all

emerge -C kdelibs

Secondly, what is the command you gave that generates the error in the first place? It looks like you might be trying to emerge the monolithic builds, rather than the split ones. It's complaining about kdebase, which I think is monolithic, not kdebase-meta, which is the split ebuild meta-package. Is that really what you want to do? If you already have the split ebuild version installed, you should probably stick with it, as the monolithic builds are supposedly going to disappear in the future. To migrate from monolithic to split ebuilds, check the official instructions: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml Decide which way you want to go (monolithic or split) and stick with it. You can't combine the two. To switch from one to the other, you have to uninstall KDE (all KDE packages!) first (according to the split ebuild documentation), because they mutually block each other. Looks like that might be what's going on for you.

[ewbish]

#emerge -c kdelibs-3.5.4-r2

--- Couldn't find 'kdelibs-3.5.4-r2' to clean.

First of all, to unmerge, you need a capital C, not a lowercase one. So, try:

Code: Select all

emerge -C kdelibs

Secondly, what is the command you gave that generates the error in the first place? It looks like you might be trying to emerge the monolithic builds, rather than the split ones. It's complaining about kdebase, which I think is monolithic, not kdebase-meta, which is the split ebuild meta-package. Is that really what you want to do? If you already have the split ebuild version installed, you should probably stick with it, as the monolithic builds are supposedly going to disappear in the future. To migrate from monolithic to split ebuilds, check the official instructions: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml Decide which way you want to go (monolithic or split) and stick with it. You can't combine the two. To switch from one to the other, you have to uninstall KDE (all KDE packages!) first (according to the split ebuild documentation), because they mutually block each other. Looks like that might be what's going on for you.

First, read "man emerge" on the -c and -C.

Second, I don't see the mono/split issue. In another thread on it, it was basically decided that the whole mono/split problem here was BS and had nothing to do with anything.

Third, the issue is a removed package (kdelib) blocking kde-env. At no time should a completely removed package block the install of another.

I agree, removing KDE and reinstalling will fix it. That is like rebuilding the engine on my car because the spark plug is bad. I would like to find the real issue here, and get it documented.

[Shan]

First, read "man emerge" on the -c and -C.

Not to be snarky but you might want to take your own advice.

emerge -c does {and I quote}

Cleans the system by removing packages that will not affect the
functionality of the system. The arguments can be ebuilds,
sets, or dependencies. For example, emerge clean binutils
cleans out old versions of binutils; emerge --clean
net-www/mozilla-0.9.9-r2 cleans out that specific version of
Mozilla. This is generally safe to use. Note that --clean does
not remove unslotted packages.

This means that if a package depends on kdelibs it will not be removed

Whereas emerge -C....

--unmerge (-C)
WARNING: This action can remove important packages! Removes all
matching packages. This does no checking of dependencies, so it
may remove packages necessary for the proper operation of your
system. Its arguments can be ebuilds, sets, or dependencies --
see --clean above for examples.

(emphasis mine both cases).

Third, the issue is a removed package (kdelib) blocking kde-env. At no time should a completely removed package block the install of another.

I highly suspect kdelibs hasn't been removed if you were using -c opposed to -C. Running "emerge -pv --nodeps kdelibs" would prove one way or another as to if its installed or not.

I agree, removing KDE and reinstalling will fix it. That is like rebuilding the engine on my car because the spark plug is bad. I would like to find the real issue here, and get it documented.

True, but then again removing the keys from the ignition doesn't remove a faulty spark-plug either. I'm honestly trying not to be a smartass here, nor a snobbish "RTFM n00b" 'helper', but when you ask someone for help it would be wise to at least listen to what information is given to you before immediately proclaiming it wrong.

For your further reading I give you real world examples from my current system:

ryn ~ # emerge -pv kdelibs

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] kde-base/kdelibs-3.5.5-r5 USE="alsa arts cups kdeenablefinal ssl -acl -debug -doc -fam -jpeg2k -kdehiddenvisibility -kerberos -legacyssl -lua -openexr -spell -tiff -utempter -xinerama -zeroconf" LINGUAS="-he" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

ryn ~ # emerge -cp kdelibs

>>> These are the packages that would be unmerged:

>>> No packages selected for removal by clean.

ryn ~ # emerge -Cp kdelibs

>>> These are the packages that would be unmerged:

kde-base/kdelibs
selected: 3.5.5-r5
protected: none
omitted: none

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

[GatorBait]

I'm having the same problems, and I'm using the KDE meta build.

Portage is referencing different versions of the kdelibs ... kdelibs-3.5.4-r2 is blocking kde-env, 3.5.5-r5 is current (and can be removed, but it isn't the blocker). I tried emege -C kdelibs, then emerge -uDv world, and kdelibs-3.5.4-r2 is still blocking kde-env.

So looks like some bad dependency in the kde update ebuilds.

*UPDATE* I added these two entries to my /etc/portage/package.mask and was able to successfully start the KDE update:
=kde-base/kdelibs-3.5.2-r6
=kde-base/kcminit-3.5.0

[MotivatedTea]

Second, I don't see the mono/split issue. In another thread on it, it was basically decided that the whole mono/split problem here was BS and had nothing to do with anything.

Hey, no need to get upset. I'm only trying to help. As I said, kdelibs is monolithic, but as far as I can tell (although I could be wrong), kdelibs is a dependency of the split ebuilds. I do know for sure that kdebase is a monolithic build. True, some people are having problems not related to monolithic/split conflicts, but it looked to me like you might be, so that's why I suggested it. Without knowing what command you typed, I can't tell for sure.

I agree, removing KDE and reinstalling will fix it. That is like rebuilding the engine on my car because the spark plug is bad. I would like to find the real issue here, and get it documented.

But you're upgrading to a new version of KDE. That means you are already "rebuilding the engine" (or perhaps "putting in a new engine" would be more apt?). You are about to re-compile every single kde-base/* package on your system, and probably a few others too. If you weren't having these dependency problems, emerge would recompile them one at a time, removing the old versions after merging in the new ones. What I suggested was removing KDE first, then re-installing the new version. It'll require just about the same amount of compiling, but is less likely to give you dependency troubles.

[ewbish]

First, read "man emerge" on the -c and -C.

Not to be snarky but you might want to take your own advice.

emerge -c does {and I quote}

Cleans the system by removing packages that will not affect the
functionality of the system. The arguments can be ebuilds,
sets, or dependencies. For example, emerge clean binutils
cleans out old versions of binutils; emerge --clean
net-www/mozilla-0.9.9-r2 cleans out that specific version of
Mozilla. This is generally safe to use. Note that --clean does
not remove unslotted packages.

This means that if a package depends on kdelibs it will not be removed

Whereas emerge -C....

--unmerge (-C)
WARNING: This action can remove important packages! Removes all
matching packages. This does no checking of dependencies, so it
may remove packages necessary for the proper operation of your
system. Its arguments can be ebuilds, sets, or dependencies --
see --clean above for examples.

(emphasis mine both cases).

Third, the issue is a removed package (kdelib) blocking kde-env. At no time should a completely removed package block the install of another.

I highly suspect kdelibs hasn't been removed if you were using -c opposed to -C. Running "emerge -pv --nodeps kdelibs" would prove one way or another as to if its installed or not.

I agree, removing KDE and reinstalling will fix it. That is like rebuilding the engine on my car because the spark plug is bad. I would like to find the real issue here, and get it documented.

True, but then again removing the keys from the ignition doesn't remove a faulty spark-plug either. I'm honestly trying not to be a smartass here, nor a snobbish "RTFM n00b" 'helper', but when you ask someone for help it would be wise to at least listen to what information is given to you before immediately proclaiming it wrong.

For your further reading I give you real world examples from my current system:

ryn ~ # emerge -pv kdelibs

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] kde-base/kdelibs-3.5.5-r5 USE="alsa arts cups kdeenablefinal ssl -acl -debug -doc -fam -jpeg2k -kdehiddenvisibility -kerberos -legacyssl -lua -openexr -spell -tiff -utempter -xinerama -zeroconf" LINGUAS="-he" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

ryn ~ # emerge -cp kdelibs

>>> These are the packages that would be unmerged:

>>> No packages selected for removal by clean.

ryn ~ # emerge -Cp kdelibs

>>> These are the packages that would be unmerged:

kde-base/kdelibs
selected: 3.5.5-r5
protected: none
omitted: none

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

Me thinks you are the noob who may need to RTFM. Look at the context. Anywhoo, your post was off topic and irrelevant, suffice it to say the package is removed and your input provided nothing to the discussion.

[ewbish]

Second, I don't see the mono/split issue. In another thread on it, it was basically decided that the whole mono/split problem here was BS and had nothing to do with anything.

Hey, no need to get upset. I'm only trying to help. As I said, kdelibs is monolithic, but as far as I can tell (although I could be wrong), kdelibs is a dependency of the split ebuilds. I do know for sure that kdebase is a monolithic build. True, some people are having problems not related to monolithic/split conflicts, but it looked to me like you might be, so that's why I suggested it. Without knowing what command you typed, I can't tell for sure.

I agree, removing KDE and reinstalling will fix it. That is like rebuilding the engine on my car because the spark plug is bad. I would like to find the real issue here, and get it documented.

But you're upgrading to a new version of KDE. That means you are already "rebuilding the engine" (or perhaps "putting in a new engine" would be more apt?). You are about to re-compile every single kde-base/* package on your system, and probably a few others too. If you weren't having these dependency problems, emerge would recompile them one at a time, removing the old versions after merging in the new ones. What I suggested was removing KDE first, then re-installing the new version. It'll require just about the same amount of compiling, but is less likely to give you dependency troubles.

Not upset, just don't see the mono/split issue. KDE was originally installed using emerge kde-meta, which according to the docs is the split packages. So, this goes back to my belief that this is an actual problem in portage.

I see your point on rebuilding, however, my analogy was driven towards portage. While we could simply work around this and fix it, the problem in portage remains. This is by no means a "clean" upgrade.

[madmaik]

Portage is referencing different versions of the kdelibs ... kdelibs-3.5.4-r2 is blocking kde-env

Sorry, but it is not. It's any version greater than or equal to (>=) 3.5.4-r2 which is correct so far.

3.5.5-r5 is current (and can be removed, but it isn't the blocker). I tried emege -C kdelibs, then emerge -uDv world, and kdelibs-3.5.4-r2 is still blocking kde-env.

Problem seems that other KDE components want kde-env installed. So portage runs into the problem as it wants to install kde-env but at the same time kdelibs-3.5.5.-r5 which includes kde-env so there is the blocking.
Haven't tried it with me yet but I think a complete uninstall of KDE before emerging 3.5.5 should do the trick.

*UPDATE* I added these two entries to my /etc/portage/package.mask and was able to successfully start the KDE update:
=kde-base/kdelibs-3.5.2-r6
=kde-base/kcminit-3.5.0

Thanks, will try that for me.

rgds,
MaDMaik

[ewbish]

I went ahead and simply emerged kde-meta again as opposed to doing an update. Cleaned everything up completely. Now I'm running emerge --update --deep world to grab the rest, but no more blockers.