Re: [gentoo-user] Still kde problems with monolithic->split

[Alan McKinnon]

On Saturday 04 October 2008 15:23:42 meino.cramer@×××.de wrote:
> Alan McKinnon <alan.mckinnon@×××××.com> [08-10-04 15:19]:
> > On Saturday 04 October 2008 15:08:36 meino.cramer@×××.de wrote:
> > > Hi,
> > >
> > > some time ago I asked what to do if kde blocks kde...
> > > The according HowTo (emergeing from monolithic
> > > to split kde install) says one has first
> > > to unmerge the old monolithic installation of
> > > kde and the install the split stuff.
> > >
> > > But regardless what I am doing...
> > > emerge -C <blocking item>
> > > shows me a rmoving action on my harddisc and
> > > the following
> > > emerge --pretend --color=n --verbose --update --deep world
> > > still shows that item being blocking new stuff.
> > > I think _physically_ the old stuff is rmoved but
> > > from emerge's point of view it is still there.
> > >
> > > How can I fix that problem ?
> >
> > You didn't give any output, so I have to guess. Most likely a different
> > package is still installed which needs the same kde you just removed and
> > that in turn conflicts with what you want to install now.
> >
> > Post the full output of 'emerge -pvuNDt world' and we'll deciphyer it for
> > you
> >
> > --
> > alan dot mckinnon at gmail dot com
>
> Hi Alan!
>
> Here it comes:
>
>
>
> These are the packages that would be merged, in reverse order:
>
> Calculating world dependencies   - app-cdr/mp3burn-0.3.3-r1 (masked by:
> package.mask) /usr/portage/profiles/package.mask:
> # Jeremy Olexa <darkside@g.o> (02 Sep 2008)
> # Removed at maintainer's request in 30 days by the treecleaners.
> # Please don't waste cds trying to use this program, bug 227143

Aside: You probably want to unmerge this one above too

[snip]

> [ebuild   R   ] kde-base/kdeartwork-3.5.9
> USE="opengl -arts* -debug -kdeenablefinal -xinerama -xscreensaver" 0 kB

That is a monolithic package, but portage wants to Replace it, which means it 
was never uninstalled. I'll give you the short version, followed by the 
(longer) explanation of what happened:

Short version: 
- unmerge all these packages (list ripped straight out from the kde ebuild)
RDEPEND="~kde-base/kdelibs-${PV}
        ~kde-base/kdebase-${PV}
        ~kde-base/kdeaddons-${PV}
        ~kde-base/kdeadmin-${PV}
        ~kde-base/kdeartwork-${PV}
        ~kde-base/kdeedu-${PV}
        ~kde-base/kdegames-${PV}
        ~kde-base/kdegraphics-${PV}
        ~kde-base/kdemultimedia-${PV}
        ~kde-base/kdenetwork-${PV}
        ~kde-base/kdepim-${PV}
        ~kde-base/kdetoys-${PV}
        ~kde-base/kdeutils-${PV}
        ~kde-base/kdewebdev-${PV}
        accessibility? ( ~kde-base/kdeaccessibility-${PV} )
- run 'emerge -av --depclean' as a sanity check. The output should be obvious, 
it might list a few more kde packages that you missed. Unmerge those, but 
note their names in case you want to put them back later
- emerge kde-meta (or if you prefer to get a smaller set instead of all of kde 
follow the handbook and emerge just the -meta packages you want)

Long version:

The traditional kde packages in portage (from long long ago) mirrored the 
organization of how the kde project released their stuff - as 16 or so huge 
packages. The kde ebuild by itself does nothing, if you look inside you'll 
see it's just a huge RDEPEND. The 16 packages in that are the ones that 
actually install kde. 

You seem to have at one point emerged kde, and got all 16 packages with it. 
Then you unmerged kde, which worked OK except that it left the other 16 in 
place, and they promptly blocked all the kde-meta stuff.

The monolithic ebuilds block the -meta ebuilds as they duplicate each other. 
You have to choose one or the other and can't mix them in any way. It may 
have been possible to write some fancy code in the -meta ebuilds to unmerge 
old packages and install the equivalent new ones but that would have been a 
major pain in the ass and is guaranteed to work for most users and completely 
destroy some other user's system. So the devs instead made the sane choice of 
forcing you to make up your mind and first setting up your machine correctly 
the way you want it. 

<humour mode on>
This is TheOneTruGentooWay(tm), a devious evil policy whereby gentoo devs 
assume that you are in fact a really super-intelligent person who can make up 
their own mind, who is absolutely not an idiot and knows what they want.

As you can see this is a wonderful way to work, but it also means that you get 
to be responsible for your own machine and wade through 100s of lines of 
portage output so you can decide what it is that you really want.
</humour mode off>

-- 
alan dot mckinnon at gmail dot com