kdelibs blocks kde-env

[kpep01]

I finally had time to get around to updating my computer. I started with gcc et al. When it came time to update world, I had several blocking issues, all of which were resolved by simply unmerging the offending applications.

kde-env was blocking kdelibs, as well as kdelibs was blocking kde-env. So, I simply unmerged those as well. Even though I unmerged kdelibs, it still shows that it is blocking kde-env. OF course, kde is pretty much broken as far as most of the appications are concerned. I did re-emerge the latest kdelibs, and managed to get a few (though not the most important items) running. The blocking problem, however, remains persistant.

I again unmerged kdelibs, but, received the same error message.

Is there a work-around to this issue that I'm not figuring out?

Thanx
_________________
There is no higher religion than human service.
To work for the common good is the highest creed.
-Albert Schweitzer

[didymos]

Try doing "equery depends kde-env". Hopefully, you'll find out what's pulling it in.
_________________
Thomas S. Howard

[kpep01]

Thanx for the reply and equery code, Didymos. I'm running revdep-rebuild at the moment to hopefully return to square one. Sadly, I can't get another shell to open at the moment, otherwise I'd run your code now.

In my later searches on this topic, I did find the same suggestion as your's. However, I couldn't find the manner in which to execute such a dependancy search. Thanx for the information. Hopefully I'll find the offending package so that it can be removed.

Thanx Again
_________________
There is no higher religion than human service.
To work for the common good is the highest creed.
-Albert Schweitzer

[sno35]

Hi
You could mask kde-env by

[Carlo]

Make sure you don't have any old KDE 3.4 ebuilds installed, unmerge kde-env. This board has a search function. Multiple threads about this blocker do exist.
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs.

[kpep01]

Thanx for the reply, Sno35. I'm still running revdep-rebuild, so haven't had a chance to even try the idea of didymos.

Perhaps I'm in error with my logic, but, wouldn't it seem best to overcome the problem with the packages which are pulling in kde-env, as opposed to simply masking it? I wonder this since the packages that are attempting to pull in kde-env seem dependant upon. Since kdelibs now includes kde-env, and since in the end I want things as up-to-date as possible, this would seem the logical direction. But, perhaps I'm in error.

Actually, since revdep-rebuild is again compiling kdelibs-3.3.3-r5, it would seem that kde-env would not be necessary. While it is true that masking would work, it would seem that it might create a problem to mask it, since other packages are still attempting to pull it in.

It would seem better to either remove (emerge -C) the offending packages, or, update them. (I tend to believe that the latter course might be preferable.) After the issue with the offending packages is solved, then "emerge -uVDN world" shoud successfully update my system based upon gcc-4.1.1. In my attempt at logic, then, the end result should be a system just like the old, while taking advantage of all of the updates et al. Nothing should remain out of date or broken (which might be the case if I simply mask kde-env).

(Of course, you still have to deal with some of the funky stuff that happens with circular dependancies and OpenOffice.org, but, that's why we have --resume I believe. Return to that stuff later.)

Anyway, while awaiting the finish of revdep-rebuild, that is the logic in my mind.

If I'm in error, I would appreciate knowing before I dig a bigger grave than is necessary.

Thanx
_________________
There is no higher religion than human service.
To work for the common good is the highest creed.
-Albert Schweitzer

[mark_alec]

Moved from Desktop Environments to Duplicate Threads.

See https://forums.gentoo.org/viewtopic-t-499984.html
_________________
www.gentoo.org.au || #gentoo-au