[gentoo-user] KDE (mono to meta) migration

[gentoo-user] KDE (mono to meta) migration

[James]

Hello,

I have looked at threads on this issue from 12jun06 
and 2jun06
and http://www.gentoo.org/doc/en/kde-split-ebuilds.xml.
By the way, this doc is good for explaining the issues,
but does not explain a clear method to perform the migration
form mono to meta......


Is there an easy way to remove all of the kde packages before
migration to kde-meta?

I like having as many kde apps installed as possible. For me,
it makes it easier to find cool (kde) softaware. But if meta 
is going away, like the monolithic kde packaging (eventually) 
I'd rather go straight to the split kde package system. 
Comments and Recommendations on kde-meta's future?



emerge -atv kde-meta 
lists many packages and I'm too lazy to remove them all by
hand....

snip
These are the packages that would be merged, in reverse order:
Calculating dependencies... done!
 .[blocks B     ] =kde-base/kdemultimedia-3.5* (is blocking kde-base/kaboodle-3.5.2)
.[blocks B     ] =kde-base/kdemultimedia-3.5* (is blocking
kde-base/kdemultimedia-kappfinder-data-3.5.2)

snip


Is there an easier way to do a bulk upgrade from mono to meta ?

>From mono to split? Some gentoo/kde systems I manage will want 
to go to the split system or a few kde-meta packages and the 
rest of the kde(split) apps individually installed.

Any enlightenment is most welcome, as I get busy quite often and do
not necessarily keep up with the latest issed on gentoo....


James



-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] KDE (mono to meta) migration

[Bo Ørsted Andresen]

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

On Thursday 22 June 2006 18:28, James wrote:
>  have looked at threads on this issue from 12jun06
> and 2jun06
> and http://www.gentoo.org/doc/en/kde-split-ebuilds.xml.
> By the way, this doc is good for explaining the issues,
> but does not explain a clear method to perform the migration
> form mono to meta......

Did you look at [1] too?

> Is there an easy way to remove all of the kde packages before
> migration to kde-meta?

Sure. But it would remove packages that the meta packages depend on too. 
kde-base/kdelibs takes a long time to compile and hence shouldn't be removed 
as you still need it. Unless of course you need to upgrade it anyway. This 
might be feasible:

#cd /var/db/pkg && emerge -Cva `ls -d kde-base/* | grep -v -r 'kdelibs\|arts'`

It will remove everything in the kde-base category except kdelibs and arts. 
Make sure to check what it removes before doing it. It shouldn't be more than 
13 packages.

[SNIP]

> But if meta 
> is going away, like the monolithic kde packaging (eventually)
> I'd rather go straight to the split kde package system.
> Comments and Recommendations on kde-meta's future?

Why would you think the kde-meta aka the split packages would be going away? 
They certainly won't.

> emerge -atv kde-meta
> lists many packages and I'm too lazy to remove them all by
> hand....

Actually there aren't a lot of monolithic packages. [1] lists them all in a 
box in section 2. If you have all of them you still need to remove only 13 
packages.

> These are the packages that would be merged, in reverse order:
> Calculating dependencies... done!
>  .[blocks B     ] =kde-base/kdemultimedia-3.5* (is blocking
> kde-base/kaboodle-3.5.2) .[blocks B     ] =kde-base/kdemultimedia-3.5* (is
> blocking
> kde-base/kdemultimedia-kappfinder-data-3.5.2)

This tells you that kde-base/kdemultimedia blocks both kaboodle and 
kdemultimedia-kappfinder-data. You only need to remove the one package 
kdemultimedia. It just blocks a lot of packages that are pulled in by 
kde-meta.

[SNIP]

> From mono to split? Some gentoo/kde systems I manage will want
> to go to the split system or a few kde-meta packages and the
> rest of the kde(split) apps individually installed.

Do what I said above or just remove the few packages manually when they block 
something. There really aren't that many. emerging any split package will 
work just as well as the meta packages. You should only use the meta packages 
if you wan't everything.

[1] http://www.gentoo.org/doc/en/kde-config.xml

-- 
Bo Andresen

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

Re: [gentoo-user] KDE (mono to meta) migration

[Neil Bothwick]

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

On Thu, 22 Jun 2006 16:28:42 +0000 (UTC), James wrote:

> Is there an easy way to remove all of the kde packages before
> migration to kde-meta?

See the thread form a couple of hours ago, but one easy way is

emerge -Ca $(ls /var/db/pkg/kde-base)

> I like having as many kde apps installed as possible. For me,
> it makes it easier to find cool (kde) softaware. But if meta 
> is going away, like the monolithic kde packaging (eventually) 
> I'd rather go straight to the split kde package system.

I think you have misunderstood the purpose of the meta packages. They are
simply empty packages that depend on various other packages. The old kde
package was a meta-package that depended on the various monolithic
builds, now there is a meta-package to replace each of the monolithic
builds that depends on the split packages. kde-meta depend on all the
split ebuilds.

> Comments and Recommendations on kde-meta's future?

The meta-packages won't be going away, they are even more important with
the split ebuilds. they aren't exclusive to KDE either; gnome,
gnome-light and xorg-x11-7* are all meta packages.


-- 
Neil Bothwick

Our bikinis are exciting. They are simply the tops.

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

[gentoo-user] Re: KDE (mono to meta) migration

[James]

Bo Ørsted Andresen <bo.andresen <at> zlin.dk> writes:

> 
> On Thursday 22 June 2006 18:28, James wrote:
> >  have looked at threads on this issue from 12jun06
> > and 2jun06
> > and http://www.gentoo.org/doc/en/kde-split-ebuilds.xml.
> > By the way, this doc is good for explaining the issues,
> > but does not explain a clear method to perform the migration
> > form mono to meta......
> 
> Did you look at [1] too?
> 
Yes, That solves how to install a new kde (mono, meta, split) but
does not really address cleanzing the sytem of all the old kde kruft.
I have stuff from kde 3.2, 3.3., 3.4 on some of my older systems.

Beside, my thoughts are to remove everthing and start from fresh, as
I seem to be tracking down a multitude of kde related trivial issues
on a variety of kde/gentoo systems I manage.


> > Is there an easy way to remove all of the kde packages before
> > migration to kde-meta?
> 
> Sure. But it would remove packages that the meta packages depend on too. 
> kde-base/kdelibs takes a long time to compile and hence shouldn't be removed 
> as you still need it. Unless of course you need to upgrade it anyway. This 
> might be feasible:
> 
> #cd /var/db/pkg && emerge -Cva `ls -d kde-base/* | grep -v -r 'kdelibs\|arts'`
> 
> It will remove everything in the kde-base category except kdelibs and arts. 
> Make sure to check what it removes before doing it. It shouldn't be more than 
> 13 packages.
> 
> [SNIP]
> 
> > But if meta 
> > is going away, like the monolithic kde packaging (eventually)
> > I'd rather go straight to the split kde package system.
> > Comments and Recommendations on kde-meta's future?
> 
> Why would you think the kde-meta aka the split packages would be going away? 
> They certainly won't.
> 
xfree_vs_xorg, dev_vs_udev,  and now kde seem to need major surgery....
Historical experiences with Gentoo. Gentoo is great for the current
new stuff, but often, I'm learning and dealing with minutia, I would 
prefer to avoid. When I do avoid the gentoo minutia, I get burned,
like now having to move to meta or split. Granted, in the long run,
these migrations have been good, but it's still painful (time consuming)
 to walk the gentoo path, at times....


> Actually there aren't a lot of monolithic packages. [1] lists them all in a 
> box in section 2. If you have all of them you still need to remove only 13 
> packages.

Well, but, on some systems, I have kde files from 3.2, 3.3 and 3.4 
and 3.5.2  now installed. I have a mess across 7 differnet gentoo
workstations. 

> 
> > These are the packages that would be merged, in reverse order:
> > Calculating dependencies... done!
> >  .[blocks B     ] =kde-base/kdemultimedia-3.5* (is blocking
> > kde-base/kaboodle-3.5.2) .[blocks B     ] =kde-base/kdemultimedia-3.5* (is
> > blocking
> > kde-base/kdemultimedia-kappfinder-data-3.5.2)
> 
> This tells you that kde-base/kdemultimedia blocks both kaboodle and 
> kdemultimedia-kappfinder-data. You only need to remove the one package 
> kdemultimedia. It just blocks a lot of packages that are pulled in by 
> kde-meta.
> 
> [SNIP]
> 
> > From mono to split? Some gentoo/kde systems I manage will want
> > to go to the split system or a few kde-meta packages and the
> > rest of the kde(split) apps individually installed.
> 
> Do what I said above or just remove the few packages manually when they block 
> something. There really aren't that many. emerging any split package will 
> work just as well as the meta packages. You should only use the meta packages 
> if you wan't everything.
> 
> [1] http://www.gentoo.org/doc/en/kde-config.xml
> 
 I'll give it a whirl......

thx,

James






-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: KDE (mono to meta) migration

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> > Is there an easy way to remove all of the kde packages before
> > migration to kde-meta?

> See the thread form a couple of hours ago,

Awe, yes, Gmane runs very slow during the day (EST), 
I see this recent discussion.



> I think you have misunderstood the purpose of the meta packages. They are
> simply empty packages that depend on various other packages. The old kde
> package was a meta-package that depended on the various monolithic
> builds, now there is a meta-package to replace each of the monolithic
> builds that depends on the split packages. kde-meta depend on all the
> split ebuilds.


Yep, this explains quite a lot.....

> > Comments and Recommendations on kde-meta's future?

> The meta-packages won't be going away, they are even more important with
> the split ebuilds. they aren't exclusive to KDE either; gnome,
> gnome-light and xorg-x11-7* are all meta packages.


Thanks for the information, this clears things up for me....

James




-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: KDE (mono to meta) migration

[Bo Ørsted Andresen]

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

Just showing a couple of tricks.

On Thursday 22 June 2006 20:15, James wrote:
> Yes, That solves how to install a new kde (mono, meta, split) but
> does not really address cleanzing the sytem of all the old kde kruft.
> I have stuff from kde 3.2, 3.3., 3.4 on some of my older systems.

This removes everything in kde-base that is version 3.2, 3.3 or 3.4 (and
installed of course):

# cd /var/db/pkg && emerge -Cva kde-base/*-3.{2,3,4}*

> > #cd /var/db/pkg && emerge -Cva `ls -d kde-base/* | grep -v -r \
> > 'kdelibs\|arts'`

One could add a version too so that only the newest version of kdelibs and
arts is kept since it is still required. Like this:

# cd /var/db/pkg && emerge -Cva  `ls kde-base | grep -v -r 'kdelibs-3\.5\.3\|arts-3\.5\.3'`

> Beside, my thoughts are to remove everthing and start from fresh, as
> I seem to be tracking down a multitude of kde related trivial issues
> on a variety of kde/gentoo systems I manage.

This removes everything in kde-base. It's equivalent to Neils suggestion.

# cd /var/db/pkg && emerge -Cva kde-base/*

Also after removing old slots there may still be third party apps left that has
been compiled against the old versions. They need to be remerged after the new
version of kde has been emerged to compile them against the new version and
remove the old cruft in /usr/kde/3.4 etc.

This will show you what packages still have cruft in /usr/kde/3.2 - 3.4:

# find /usr/kde/3.{2,3,4} | xargs equery belongs | cat

Unmerge what you don't need or remerge (after emerging kde 3.5) what you still
need. When you are done with that the above command should give no output and
any files still in /usr/kde/3.2 - 3.4 can be safely deleted since they belong
to no package. Pay attention to what you do though. A revdep-rebuild before
this step will probably take care of most of this.

> xfree_vs_xorg, dev_vs_udev,  and now kde seem to need major surgery....
> Historical experiences with Gentoo. Gentoo is great for the current
> new stuff, but often, I'm learning and dealing with minutia, I would
> prefer to avoid. When I do avoid the gentoo minutia, I get burned,
> like now having to move to meta or split. Granted, in the long run,
> these migrations have been good, but it's still painful (time consuming)
>  to walk the gentoo path, at times....

The split packages are replacing the monolithic. Not the other way around. And
KDE 4.x will get out next spring.

-- 
Bo Andresen

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

[gentoo-user] Re: KDE (mono to meta) migration

[James]

Bo Ørsted Andresen <bo.andresen <at> zlin.dk> writes:


> This removes everything in kde-base that is version 3.2, 3.3 or 3.4 (and
> installed of course):

> # cd /var/db/pkg && emerge -Cva kde-base/*-3.{2,3,4}*

Used this one. I'd rather clean it all out (KDE) and start over.


> This removes everything in kde-base. It's equivalent to Neils suggestion.

> # cd /var/db/pkg && emerge -Cva kde-base/*

I then removed the monolithci packages by hand that are blocking
This is the command I used to see what is(was) blocking kde-meta:
emerge -uavDN kde-meta


> Also after removing old slots there may still be third party apps left that has
> been compiled against the old versions. They need to be remerged after the new
> version of kde has been emerged to compile them against the new version and
> remove the old cruft in /usr/kde/3.4 etc.

> This will show you what packages still have cruft in /usr/kde/3.2 - 3.4:

> # find /usr/kde/3.{2,3,4} | xargs equery belongs | cat

Ok I'll do this after emerging kde-meta completes. I hope I was not suppose
to do this before 'emerge -uavDN kde-meta' ????

Right now the (test) workstation is compiling kde-meta. When that is done,
I'll report back my results. This way, maybe other folks can have a
concise method to clean out the old kde kruft and get fresh kde-meta
or kde-split(dealer's choice...)

> Unmerge what you don't need or remerge (after emerging kde 3.5) what you still
> need. When you are done with that the above command should give no output and
> any files still in /usr/kde/3.2 - 3.4 can be safely deleted since they belong
> to no package. Pay attention to what you do though. A revdep-rebuild before
> this step will probably take care of most of this.

Before or after the emerge -uavDN kde-meta?


James




-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: KDE (mono to meta) migration

[Bo Ørsted Andresen]

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

On Thursday 22 June 2006 22:12, James wrote:
> Ok I'll do this after emerging kde-meta completes. I hope I was not suppose
> to do this before 'emerge -uavDN kde-meta' ????

You weren't. Blocks are only within the same slot. In fact the split packages 
blocks only the monolithic package they belong to.

[SNIP]

> > Unmerge what you don't need or remerge (after emerging kde 3.5) what you
> > still need. When you are done with that the above command should give no
> > output and any files still in /usr/kde/3.2 - 3.4 can be safely deleted
> > since they belong to no package. Pay attention to what you do though. A
> > revdep-rebuild before this step will probably take care of most of this.
>
> Before or after the emerge -uavDN kde-meta?

If you are removing stuff it doesn't matter. If you are remerging stuff it 
should be after. If you do it before it will be built against the old version 
again which is pretty pointless.

-- 
Bo Andresen

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

Re: [gentoo-user] Re: KDE (mono to meta) migration

[Mick]

On 22/06/06, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:

> This will show you what packages still have cruft in /usr/kde/3.2 - 3.4:
>
> # find /usr/kde/3.{2,3,4} | xargs equery belongs | cat

It aborts on mine:
==============================
# find /usr/kde/3.{2,3,4} | xargs equery belongs | cat
find: /usr/kde/3.2: No such file or directory
find: /usr/kde/3.3: No such file or directory
find: /usr/kde/3.4: No such file or directory
List all packages owning a particular set of files

Note: Normally, only one package will own a file. If multiple packages
own the same file, it usually consitutes a problem, and should be
reported.

Syntax:
  belongs <local-opts> filename
<local-opts> is either of:
  -c, --category cat - only search in category cat
  -f, --full-regex   - supplied query is a regex
  -e, --earlyout     - stop when first match is found
  -n, --name-only    - don't print the version.
xargs: equery: exited with status 255; aborting
==============================

What gives?
-- 
Regards,
Mick

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: KDE (mono to meta) migration

[Bo Ørsted Andresen]

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

On Thursday 22 June 2006 23:48, Mick wrote:
> It aborts on mine:
> ==============================
> # find /usr/kde/3.{2,3,4} | xargs equery belongs | cat
> find: /usr/kde/3.2: No such file or directory
> find: /usr/kde/3.3: No such file or directory
> find: /usr/kde/3.4: No such file or directory
> List all packages owning a particular set of files

Obviously you don't have any cruft from 3.2, 3.3 or 3.4 on that system. So all 
is good.

-- 
Bo Andresen

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

Re: [gentoo-user] Re: KDE (mono to meta) migration

[Mick]

On 22/06/06, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:

> Obviously you don't have any cruft from 3.2, 3.3 or 3.4 on that system. So all
> is good.

Phew!  :-))

Thanks for the nice tips!  I have bookmarked it.
-- 
Regards,
Mick

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: KDE (mono to meta) migration

[James]

Bo Ørsted Andresen <bo.andresen <at> zlin.dk> writes:


> On Thursday 22 June 2006 22:12, James wrote:
> > Ok I'll do this after emerging kde-meta completes. I hope I 
was not suppose
> > to do this before 'emerge -uavDN kde-meta' ????

> You weren't. Blocks are only within the same slot. In fact the 
split packages 
> blocks only the monolithic package they belong to.

OK

 Unmerge what you don't need or remerge (after emerging kde 3.5) what you
 still need. When you are done with that the above command should give no
 output and any files still in /usr/kde/3.2 - 3.4 can be safely deleted
 since they belong to no package. Pay attention to what you do though. A
 revdep-rebuild before this step will probably take care of most of this.

> > Before or after the emerge -uavDN kde-meta?

> If you are removing stuff it doesn't matter. If you are remerging 
stuff it 
> should be after. If you do it before it will be built against the 
old version 
> again which is pretty pointless.

Well, something is messed up. I still get many many blocks:


 =kde-base/kdepim-3.5* (is blocking 
kde-base/libkpgp-3.5.0-r1) [blocks B     ] =kde-base/kdepim-3.5* (is 
blocking 
kde-base/libkdenetwork-3.5.0)
 [blocks B     ] =kde-base/kdepim-3.5* (is 
blocking kde-base/libkpimidentities-3.5.2)
 [blocks B     ] =kde-base/kdepim-3.5*  (is 
blocking kde-base/libkdepim-3.5.2-r1)
 [blocks B     ] =kde-base/kdepim-3.5* (is 
blocking kde-base/libkcal-3.5.2-r1)  
                                                                    

<snip>
[blocks B     ] =kde-base/kdegraphics-3.5* 
(is blocking kde-base/kamera-3.5.2)
[blocks B     ] =kde-base/kdegraphics-3.5* 
(is blocking kde-base/kghostview-3.5.2)
[blocks B     ] =kde-base/kdegraphics-3.5* (is blocking
kde-base/kcoloredit-3.5.2)                                                     
            
<snip>

I after deleting  everything. I unmerge everthing (KDE) I thought:
467    emerge --unmerge kde-base/kdewebdev
  468    emerge --unmerge kde-base/kdeadmin
 470    emerge --unmerge kde-base/kdemultimedia
  471    emerge --unmerge kde-base/kdepim
  472    emerge --unmerge kde-base/kdeutils
 475    emerge --unmerge kde-base/kdetoys
  477  emerge --unmerge kde-base/kdegraphics
 480  emerge --unmerge kde-base/kdenetwork
<snip>

but they are still blocking?

I tried revdep-rebuild
emerge --rsync  and
env-update && source /etc/profile && etc-update && 
update-eix && eupdatedb


Yet the system think they are gone, for example:

emerge --unmerge kde-base/kdegraphics
--- Couldn't find 'kde-base/kdegraphics' to unmerge.

Yet is still one of the blocking packages?

[blocks B     ] =kde-base/kdegraphics-3.5* (is blocking kde-base/kuickshow-3.5.2)
.[blocks B     ] =kde-base/kdegraphics-3.5* 
(is blocking kde-base/kgamma-3.5.2)
.[blocks B     ] =kde-base/kdegraphics-3.5* 
(is blocking kde-base/kmrml-3.5.2) 
                                                                     
snip

What did I miss?


James





-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: KDE (mono to meta) migration

[Bo Ørsted Andresen]

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

Your quoting style is terrible...!

On Saturday 24 June 2006 17:25, James wrote:
> > > >  Unmerge what you don't need or remerge (after emerging kde 3.5) what
> > > >  you still need. When you are done with that the above command should
> > > >  give no output and any files still in /usr/kde/3.2 - 3.4 can be
> > > >  safely deleted since they belong to no package. Pay attention to what
> > > >  you do though. A revdep-rebuild before this step will probably take
> > > >  care of most of this. 

Here I was talking about cleaning out the cruft that third party applications 
that do not belong to KDE may leave behind after you have removed KDE from an 
old slot. This has nothing to do with the problems below. It is relevant when 
you are done upgrading kde and not before.

[SNIP]

> Well, something is messed up. I still get many many blocks:
>
> [blocks B     ] =kde-base/kdepim-3.5* (is blocking
> kde-base/libkpgp-3.5.0-r1)  
[SNIP]

> [blocks B     ] =kde-base/kdegraphics-3.5*
> (is blocking kde-base/kamera-3.5.2)

> I after deleting  everything. I unmerge everthing (KDE) I thought:
> 467    emerge --unmerge kde-base/kdewebdev
>   468    emerge --unmerge kde-base/kdeadmin
>  470    emerge --unmerge kde-base/kdemultimedia
>   471    emerge --unmerge kde-base/kdepim
>   472    emerge --unmerge kde-base/kdeutils
>  475    emerge --unmerge kde-base/kdetoys
>   477  emerge --unmerge kde-base/kdegraphics
>  480  emerge --unmerge kde-base/kdenetwork
> <snip>

> but they are still blocking?

Did you unmerge kde? It depends on the monolithic packages above.

# emerge --unmerge kde

> I tried revdep-rebuild
> emerge --rsync  and
> env-update && source /etc/profile && etc-update &&
> update-eix && eupdatedb

That's pretty pointless at the moment. When you don't know what is pulling 
something in you should add --tree to the emerge command.

-- 
Bo Andresen

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

[gentoo-user] Re: KDE (mono to meta) migration

[James]

Bo Ørsted Andresen <bo.andresen <at> zlin.dk> writes:


> You weren't. Blocks are only within the same slot. In fact the split packages 
> blocks only the monolithic package they belong to.


Sorry, my last response got butchered. Gmane get's rediculous somethings
borderline upsurd on it's request to make lines shorter and other response
formating issues.

I have gotten ride of all of the blocking, by unmerging everthing kde I could 
find:

525   emerge --unmerge kde-base/kdegraphics
526  emerge --unmerge kde-base/kdemultimedia
<snip>

> > Before or after the emerge -uavDN kde-meta?

> If you are removing stuff it doesn't matter. If you are remerging stuff it 
> should be after. If you do it before it will be built against the old version 
> again which is pretty pointless.

another  pair of 'revdep-rebuild' seemed to have worked?

However, the last time I did this I got a ton of blocking isses.
One more retry. I post again if this does not work.


One of the KDE devs should put out a tool or script to completely
nuke kde, then let folks run 
emerge -uavDN kde-meta' and be done with it. Disk space is cheap
and I do not have time to 'hack' at kde across 7 workstations.
Re compiling everything from from scratch is no bid deal. Waisting
lots of timer, per machine to migrate from monolithic to meta
has wasted quite a lot of time, and I still have 6 more machines to go.

So on the next machine, here's my steps to completely nuke kde
install kde-meta:

First:
# emerge --unmerge kde-base/kdeartwork
# emerge --unmerge kde-base/kdegames
# emerge --unmerge kde-base/kdeaddons
# emerge --unmerge kde-base/kdewebdev
# emerge --unmerge kde-base/kdeadmin
# emerge --unmerge kde-base/kdegraphics
# emerge --unmerge kde-base/kdemultimedia
# emerge --unmerge kde-base/kdepim
# emerge --unmerge kde-base/kdeutils
# emerge --unmerge kde-base/kdeedu
# emerge --unmerge kde-base/kdebase
# emerge --unmerge kde-base/kdetoys


Second:
<Now remove all old kde 3.2, 3.3, and 3.4 kruft>
# cd /var/db/pkg && emerge -Cva kde-base/*-3.{2,3,4}* 
# env-update && source /etc/profile && etc-update && update-eix && eupdatedb

Third:
<clean up broken links>
# revdep-rebuild -p
# revdep-rebuild
# emerge --sync
# env-update && source /etc/profile && etc-update

Fourth:
<install kde-meta>
emerge -uavDNp kde-meta
<if blocking occurs, unmerge clocking packages and return to Second>

emerge -uavDN kde-meta


Did I miss anything? Did I get anything out of order?
Please edit to make this a mechanical process, or add in 
options at the right place to go the selection of
individual kde packages after installing kdebase-meta?


PS I sure hope this helps other avoid this time-sync.
sincerely,
James







James







-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: KDE (mono to meta) migration

[Bo Ørsted Andresen]

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

On Saturday 24 June 2006 18:05, James wrote:
> One of the KDE devs should put out a tool or script to completely
> nuke kde, then let folks run
> emerge -uavDN kde-meta' and be done with it. Disk space is cheap
> and I do not have time to 'hack' at kde across 7 workstations.
> Re compiling everything from from scratch is no bid deal. Waisting
> lots of timer, per machine to migrate from monolithic to meta
> has wasted quite a lot of time, and I still have 6 more machines to go.

You seem to have been more confused than enlightened by the tricks I posted.
If you want to nuke kde completely you should just do:

# cd /var/db/pkg && emerge -Cva kde-base/*

It's as simple as that. Both Neil and I told you that a long time ago. This
nukes both new and old slots. Both split and monolithic. And allows you to
start with kde from scratch.

> So on the next machine, here's my steps to completely nuke kde
> install kde-meta:
>
> First:
[SNIP]

There is no reason call emerge 12 times. Just use one command:

# emerge --unmerge 
kde-base/kde{,artwork,games,addons,webdev,admin,graphics,multimedia,pim,utils,edu,base,toys}

That changes nothing though (except you forgot to unmerge kde-base/kde - the
above command includes that too). And this is unnecessary if you nuked kde 
completely.

> Second:
> <Now remove all old kde 3.2, 3.3, and 3.4 kruft>
> # cd /var/db/pkg && emerge -Cva kde-base/*-3.{2,3,4}*

That also is only necessary if you did not nuke kde completely.

> # env-update && source /etc/profile && etc-update && update-eix && eupdatedb

This is completely pointless after unmerging something.

> Third:
> <clean up broken links>
> # revdep-rebuild -p
> # revdep-rebuild

You can do that after emerging kde-meta-3.5. No reason to do it before.

> # emerge --sync
> # env-update && source /etc/profile && etc-update

Again this is completely pointless at this time.

> Fourth:
> <install kde-meta>
> emerge -uavDNp kde-meta
> <if blocking occurs, unmerge clocking packages and return to Second>
> emerge -uavDN kde-meta

Blocking won't occur if you already removed the monolithic packages.

> Did I miss anything? Did I get anything out of order?
> Please edit to make this a mechanical process, or add in
> options at the right place to go the selection of
> individual kde packages after installing kdebase-meta?

Now you should run revdep-rebuild. You need to make up your mind if you want 
to nuke everything or not. You keep saying you want to nuke kde completely 
and yet follow advice that avoids nuking it completely. Assuming you really 
do want to nuke kde completely (on your other computers):

# cd /var/db/pkg && emerge -Cva kde-base/*
# emerge -uva kde-meta
# revdep-rebuild -p
# revdep-rebuild

-- 
Bo Andresen

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

[gentoo-user] Re: KDE (mono to meta) migration

[James]

Bo Ørsted Andresen <bo.andresen <at> zlin.dk> writes:


> You seem to have been more confused than enlightened by the tricks I posted.
> If you want to nuke kde completely you should just do:

> # cd /var/db/pkg && emerge -Cva kde-base/*

> It's as simple as that. Both Neil and I told you that a long time ago. This
> nukes both new and old slots. Both split and monolithic. And allows you to
> start with kde from scratch.


OK my bad/stupid/ineptness..... OK?

Are these simple steps going to work?
If not please edit. I do not care about
extra compile time. I need a simple straightforward method
to nuke(&&unistall all of KDE) and install via kde-meta


First:# 
<nuke all occurances of kde>
cd /var/db/pkg && emerge -Cva kde-base/*


Second:
<Ensure all the old kde kruft is gone 3.2, 3.3, and 3.4 
# cd /var/db/pkg && emerge -Cva kde-base/*-3.{2,3,4}*
# env-update && source /etc/profile && etc-update && update-eix &&
# eupdatedb

Third:
<clean up broken links>
# revdep-rebuild -p
# revdep-rebuild
# emerge --sync
# env-update && source /etc/profile && etc-update

Fourth:
<install kde-meta>
# emerge -uavDNp kde-meta
<if blocking occurs, unmerge blocking packages and return to First>
# emerge -uavDN kde-meta


Did I miss anything? Did I get anything out of order?
Everyting went well, I just had lots of blocking packages when
I did not expect too....?


(sorry about being a grouch.... lack of sleep...>


James



-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: KDE (mono to meta) migration

[Bo Ørsted Andresen]

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

On Saturday 24 June 2006 19:21, James wrote:
> Are these simple steps going to work?
> If not please edit. I do not care about
> extra compile time. I need a simple straightforward method
> to nuke(&&unistall all of KDE) and install via kde-meta
>
> First:#
> <nuke all occurances of kde>
> cd /var/db/pkg && emerge -Cva kde-base/*

Good.

> Second:
> <Ensure all the old kde kruft is gone 3.2, 3.3, and 3.4
> # cd /var/db/pkg && emerge -Cva kde-base/*-3.{2,3,4}*

This removes *nothing* that the first step didn't already remove.

> # env-update && source /etc/profile && etc-update && update-eix &&
> # eupdatedb

This is still pointless. It does no harm and it changes nothing.

> Third:
> <clean up broken links>
> # revdep-rebuild -p
> # revdep-rebuild
> # emerge --sync
> # env-update && source /etc/profile && etc-update

Still pointless at this time.

> Fourth:
> <install kde-meta>
> # emerge -uavDNp kde-meta

Good.

> <if blocking occurs, unmerge blocking packages and return to First>
> # emerge -uavDN kde-meta

Nothing will block if you followed the first step.

> Did I miss anything? Did I get anything out of order?
> Everyting went well, I just had lots of blocking packages when
> I did not expect too....?

The revdep-rebuild is good *after* emerging kde-meta. It will recompile third 
party applications such as amarok against the new version of kde-meta. I 
posted the simple steps at the bottom of my previous mail.

-- 
Bo Andresen

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

[gentoo-user] Re: KDE (mono to meta) migration

[James]

Bo Ørsted Andresen <bo.andresen <at> zlin.dk> writes:

 The revdep-rebuild is good *after* emerging kde-meta. It will recompile third 
 party applications such as amarok against the new version of kde-meta. I 
 posted the simple steps at the bottom of my previous mail.


Assuming you really 
do want to nuke kde completely (on your other computers):

# cd /var/db/pkg && emerge -Cva kde-base/*
# emerge -uva kde-meta
# revdep-rebuild -p
# revdep-rebuild

Yep these 4 lines do the trick. Multiple applications of revdep-rebuild


thx.


James



-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: KDE (mono to meta) migration

[Neil Bothwick]

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

On Sat, 24 Jun 2006 18:28:39 +0200, Bo Ørsted Andresen wrote:

> You seem to have been more confused than enlightened by the tricks I
> posted. If you want to nuke kde completely you should just do:
> 
> # cd /var/db/pkg && emerge -Cva kde-base/*

You should also "rm -fr /usr/kde" or "rm -fr /usr/kde/3.[0-4]" if you
want to keep 3.5. This removes files that were not deleted by the
unmerge. This includes anything that had changed during installation,
such as config files and any library files that fix_libtools_files.sh may
have changed.


-- 
Neil Bothwick

Everything's back to normal. Damn.

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