[gentoo-user] KDE3 removal

[gentoo-user] KDE3 removal

[James]

Hello,

I've been updating a kde3 workstation to kde4
off and on for a few days now. KDE4 is installed
and seem to work, no extensive testing yet.

However, when I run revdep-rebuild, it complains
about numerous kde3 based packages. Most, if not all
had the kde4 equivalent packages installed. So I just
manually deleted the list of kde3.5.x based packages.
<snip>

So a few more manual passes of removing the offending kde-3.5.x
packages and I'm down to this list of packages that
revdep-rebuild wants to rebuild:

I get the list from revdep-rebuild, research if I want the 
packages and then clean out the (crufted) revdep-rebuild 
list and continue until I'm down to these packages:


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

Calculating dependencies... done!
[ebuild  N    ] sys-fs/device-mapper-1.02.24-r1  USE="(-selinux)"
[ebuild     U ] media-libs/lcms-1.18-r1 [1.17]
[ebuild   R   ] sys-fs/cryptsetup-1.0.6-r2
[ebuild   R   ] net-libs/xulrunner-1.8.1.19
[ebuild     U ] net-libs/xulrunner-1.9.1.4 [1.9.0.7] USE="alsa%* python%*
-debug% -sqlite% -startup-notification*"
[ebuild   R   ] sys-apps/hal-0.5.12_rc1-r8


So far so good. I did not actually allow revdep-rebuild to
complete, as I want all vestiges of kde3 and other cruft gone.

Now I have a list I can focus on, except, I'm confused about
device-mapper, ,cryptsetup, and xulrunner as my research suggest 
device-mapper is not needed, but it is being call by:
[ Searching for packages depending on device-mapper... ]
sys-fs/cryptsetup-1.0.6-r2 (>=sys-fs/device-mapper-1.00.07-r1)


Research suggests that I can install lvm2 and be done with that? But it 
first wants to call back device-mapper?


Now, guidance here is appreciated.


James

Re: [gentoo-user] KDE3 removal

[Alan McKinnon]

On Wednesday 25 November 2009 18:54:54 James wrote:
> Hello,
> 
> I've been updating a kde3 workstation to kde4
> off and on for a few days now. KDE4 is installed
> and seem to work, no extensive testing yet.
> 
> However, when I run revdep-rebuild, it complains
> about numerous kde3 based packages. Most, if not all
> had the kde4 equivalent packages installed. So I just
> manually deleted the list of kde3.5.x based packages.
> <snip>
> 
> So a few more manual passes of removing the offending kde-3.5.x
> packages and I'm down to this list of packages that
> revdep-rebuild wants to rebuild:
> 
> I get the list from revdep-rebuild, research if I want the
> packages and then clean out the (crufted) revdep-rebuild
> list and continue until I'm down to these packages:
> 
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild  N    ] sys-fs/device-mapper-1.02.24-r1  USE="(-selinux)"
> [ebuild     U ] media-libs/lcms-1.18-r1 [1.17]
> [ebuild   R   ] sys-fs/cryptsetup-1.0.6-r2
> [ebuild   R   ] net-libs/xulrunner-1.8.1.19
> [ebuild     U ] net-libs/xulrunner-1.9.1.4 [1.9.0.7] USE="alsa%* python%*
> -debug% -sqlite% -startup-notification*"
> [ebuild   R   ] sys-apps/hal-0.5.12_rc1-r8
> 
> 
> So far so good. I did not actually allow revdep-rebuild to
> complete, as I want all vestiges of kde3 and other cruft gone.
> 
> Now I have a list I can focus on, except, I'm confused about
> device-mapper, ,cryptsetup, and xulrunner as my research suggest
> device-mapper is not needed, but it is being call by:
> [ Searching for packages depending on device-mapper... ]
> sys-fs/cryptsetup-1.0.6-r2 (>=sys-fs/device-mapper-1.00.07-r1)
> 
> 
> Research suggests that I can install lvm2 and be done with that? But it
> first wants to call back device-mapper?

device-mapper has been moved into lvm2 as only it and crypt really use it. 
Just bypass revdep-rebuild for this and install lvm2, then possibly reboot and 
remove device-mapper.

I find it odd that you have two SLOTs of xulrunner. These days we tend to need 
only one at a time. Perhaps you have both in world; what does equery depends 
have to say about those packages?

For the rest, just let revdep-rebuild rebuild them

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: KDE3 removal

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:


> device-mapper has been moved into lvm2 as only it and crypt really use it. 
> Just bypass revdep-rebuild for this and install lvm2, then possibly reboot and 
> remove device-mapper.

Well revdep-rebuild finally shows clear.

After updating and syncing, I get this upon trying to update world:

[ebuild     U ] sys-apps/kbd-1.15 [1.13-r1]
[ebuild     U ] sys-fs/udev-147-r1 [147]
[uninstall    ] sys-fs/device-mapper-1.02.24-r1
[blocks b     ] sys-fs/device-mapper ("sys-fs/device-mapper" is blocking
sys-fs/udev-147-r1)
[blocks B     ] <sys-fs/lvm2-2.02.45 ("<sys-fs/lvm2-2.02.45" is blocking
sys-fs/udev-147-r1)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  ('installed', '/', 'sys-fs/lvm2-2.02.36', 'nomerge') pulled in by
    sys-fs/lvm2 required by world

  ('ebuild', '/', 'sys-fs/udev-147-r1', 'merge') pulled in by
    virtual/dev-manager required by world



> I find it odd that you have two SLOTs of xulrunner. These days we tend to need 
> only one at a time. Perhaps you have both in world; what does equery depends 
> have to say about those packages?


Installed versions:  1.8.1.19(1.8)(16:50:24 11/25/09)(gnome ipv6 java -debug
-elibc_FreeBSD -xinerama) 1.9.1.4(1.9)(17:22:06 11/25/09)(alsa dbus gnome java
python -custom-optimization -debug -elibc_FreeBSD -sqlite -startup-notification)
     Homepage:            http://developer.mozilla.org/en/docs/XULRunner
     Description:         Mozilla runtime package that can be used to bootstrap
XUL+XPCOM applications



I think swt and eclispe 3.4 are calling for the second xulrunner....?

using equery depends ......


James

Re: [gentoo-user] Re: KDE3 removal

[Alan McKinnon]

On Thursday 26 November 2009 00:23:04 James wrote:
> Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
> > device-mapper has been moved into lvm2 as only it and crypt really use
> > it. Just bypass revdep-rebuild for this and install lvm2, then possibly
> > reboot and remove device-mapper.
> 
> Well revdep-rebuild finally shows clear.
> 
> After updating and syncing, I get this upon trying to update world:
> 
> [ebuild     U ] sys-apps/kbd-1.15 [1.13-r1]
> [ebuild     U ] sys-fs/udev-147-r1 [147]
> [uninstall    ] sys-fs/device-mapper-1.02.24-r1
> [blocks b     ] sys-fs/device-mapper ("sys-fs/device-mapper" is blocking
> sys-fs/udev-147-r1)
> [blocks B     ] <sys-fs/lvm2-2.02.45 ("<sys-fs/lvm2-2.02.45" is blocking
> sys-fs/udev-147-r1)
> 
>  * Error: The above package list contains packages which cannot be
>  * installed at the same time on the same system.
> 
>   ('installed', '/', 'sys-fs/lvm2-2.02.36', 'nomerge') pulled in by
>     sys-fs/lvm2 required by world
> 
>   ('ebuild', '/', 'sys-fs/udev-147-r1', 'merge') pulled in by
>     virtual/dev-manager required by world

emerge -C device-mapper && emerge lvm2 udev

> > I find it odd that you have two SLOTs of xulrunner. These days we tend to
> > need only one at a time. Perhaps you have both in world; what does equery
> > depends have to say about those packages?
> 
> Installed versions:  1.8.1.19(1.8)(16:50:24 11/25/09)(gnome ipv6 java
>  -debug -elibc_FreeBSD -xinerama) 1.9.1.4(1.9)(17:22:06 11/25/09)(alsa dbus
>  gnome java python -custom-optimization -debug -elibc_FreeBSD -sqlite
>  -startup-notification) Homepage:           
>  http://developer.mozilla.org/en/docs/XULRunner Description:        
>  Mozilla runtime package that can be used to bootstrap XUL+XPCOM
>  applications
> 
> 
> 
> I think swt and eclispe 3.4 are calling for the second xulrunner....?

swt version 3.4 and 3.5 DEPEND on xulrunner:1.9
swt version 3.3 DEPENDs on xulrunner:1.8

eclipse doesn't DEPEND on xulrunner at all, but various other things do. 
equery depends -a xulrunner:1.8 lists about 40 possibilities here.


-- 
alan dot mckinnon at gmail dot com

[gentoo-user] FIXED: Re: KDE3 removal

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:


> emerge -C device-mapper && emerge lvm2 udev


Yep, mix in an extra reboot and it's all fine now!


> eclipse doesn't DEPEND on xulrunner at all, but various other things do. 
> equery depends -a xulrunner:1.8 lists about 40 possibilities here.

eclipse depends on SWT. SWT depends on xulrunner. sorry,
I should have been more clear, I did not pay closer attention
to the 1.8 vs 1.9 issues....thanks.

The system is already gone, so I'll be another 6-9 months
before I see it again..... 

kde-4.3.1 went smooth, except
for I have to manually removed all the kde-3.5 packages.
It had kde-meta-3.5.10. Is there some syntax or a better
method to insure all the kde-3.5.x packages are removed,
without a manual sweep?


Thanks Alan.


James

Re: [gentoo-user] FIXED: Re: KDE3 removal

[Alan McKinnon]

On Thursday 26 November 2009 19:34:34 James wrote:
> kde-4.3.1 went smooth, except
> for I have to manually removed all the kde-3.5 packages.
> It had kde-meta-3.5.10. Is there some syntax or a better
> method to insure all the kde-3.5.x packages are removed,
> without a manual sweep?
> 

grep kde /var/lib/portage/world
and eyeball the output. There should only be -meta packages, and individual 
packages for which you have NOT installed the -meta package, in there. vi the 
world file and remove the stuff that shouldn't be there, then

emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] FIXED: Re: KDE3 removal

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2916 bytes --]

On Thursday 26 November 2009 19:20:26 Alan McKinnon wrote:
> On Thursday 26 November 2009 19:34:34 James wrote:
> > kde-4.3.1 went smooth, except
> > for I have to manually removed all the kde-3.5 packages.
> > It had kde-meta-3.5.10. Is there some syntax or a better
> > method to insure all the kde-3.5.x packages are removed,
> > without a manual sweep?
> 
> grep kde /var/lib/portage/world
> and eyeball the output. There should only be -meta packages, and individual
> packages for which you have NOT installed the -meta package, in there. vi
>  the world file and remove the stuff that shouldn't be there, then

That's a good point ... over the years I have accumulated all sorts of 
packages I am not sure I need (by forgetting to use --oneshot).  Should these 
be in there?
================================
kde-base/akregator
kde-base/ark
kde-base/drkonqi
kde-base/kaddressbook
kde-base/kappfinder
kde-base/kate
kde-base/kcalc
kde-base/kcharselect
kde-base/kcheckpass
kde-base/kcminit
kde-base/kcontrol
kde-base/kcron
kde-base/kdeadmin-meta  <--Yes
kde-base/kdeartwork-emoticons
kde-base/kdeartwork-iconthemes
kde-base/kdeartwork-kscreensaver
kde-base/kdeartwork-meta  <--Yes
kde-base/kdeartwork-sounds
kde-base/kdeartwork-styles
kde-base/kdeartwork-wallpapers
kde-base/kdebase-data
kde-base/kdebase-kioslaves
kde-base/kdebase-meta  <--Yes
kde-base/kdebase-startkde
kde-base/kdebugdialog
kde-base/kdegraphics-meta  <--Yes
kde-base/kdelibs
kde-base/kdemultimedia-kioslaves
kde-base/kdemultimedia-meta  <--Yes
kde-base/kdenetwork-filesharing
kde-base/kdenetwork-meta  <--Yes
kde-base/kdepasswd
kde-base/kdepim-meta  <--Yes
kde-base/kdesu
kde-base/kdeutils-meta  <--Yes
kde-base/kdewebdev-meta  <--Yes
kde-base/kdf
kde-base/kdialog
kde-base/kdm
kde-base/kdnssd
kde-base/kfilereplace
kde-base/kfloppy
kde-base/kgamma
kde-base/kget
kde-base/kghostview
kde-base/kgpg
kde-base/khelpcenter
kde-base/khotkeys
kde-base/kicker
kde-base/kimagemapeditor
kde-base/kjots
kde-base/klinkstatus
kde-base/klipper
kde-base/kmail
kde-base/kmenuedit
kde-base/kmix
kde-base/knetattach
kde-base/knetworkconf
kde-base/kolourpaint
kde-base/kommander
kde-base/konqueror
kde-base/konsole
kde-base/kontact
kde-base/kopete
kde-base/kppp
kde-base/krdc
kde-base/kreadconfig
kde-base/krfb
kde-base/kruler
kde-base/kscd
kde-base/kscreensaver
kde-base/ksmserver
kde-base/ksnapshot
kde-base/kstart
kde-base/ksysguard
kde-base/ksystraycmd
kde-base/ktimer
kde-base/kuser
kde-base/kweather
kde-base/kwin
kde-base/kxsldbg
kde-base/libkcddb
kde-base/libkdepim
kde-base/libkonq
kde-base/nsplugins
================================

Other than the metas which I have marked with "<--Yes" I'm not sure I need the 
rest.  Shall I blow them away?

> emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean
> 

-- 
Regards,
Mick

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

Re: [gentoo-user] FIXED: Re: KDE3 removal

[Dale]

>
> That's a good point ... over the years I have accumulated all sorts of
> packages I am not sure I need (by forgetting to use --oneshot).  Should these
> be in there?
> ================================
> kde-base/akregator
> kde-base/ark
> kde-base/drkonqi
> kde-base/kaddressbook
> kde-base/kappfinder
> kde-base/kate
> kde-base/kcalc
> kde-base/kcharselect
> kde-base/kcheckpass
> kde-base/kcminit
> kde-base/kcontrol
> kde-base/kcron
> kde-base/kdeadmin-meta<--Yes
> kde-base/kdeartwork-emoticons
> kde-base/kdeartwork-iconthemes
> kde-base/kdeartwork-kscreensaver
> kde-base/kdeartwork-meta<--Yes
> kde-base/kdeartwork-sounds
> kde-base/kdeartwork-styles
> kde-base/kdeartwork-wallpapers
> kde-base/kdebase-data
> kde-base/kdebase-kioslaves
> kde-base/kdebase-meta<--Yes
> kde-base/kdebase-startkde
> kde-base/kdebugdialog
> kde-base/kdegraphics-meta<--Yes
> kde-base/kdelibs
> kde-base/kdemultimedia-kioslaves
> kde-base/kdemultimedia-meta<--Yes
> kde-base/kdenetwork-filesharing
> kde-base/kdenetwork-meta<--Yes
> kde-base/kdepasswd
> kde-base/kdepim-meta<--Yes
> kde-base/kdesu
> kde-base/kdeutils-meta<--Yes
> kde-base/kdewebdev-meta<--Yes
> kde-base/kdf
> kde-base/kdialog
> kde-base/kdm
> kde-base/kdnssd
> kde-base/kfilereplace
> kde-base/kfloppy
> kde-base/kgamma
> kde-base/kget
> kde-base/kghostview
> kde-base/kgpg
> kde-base/khelpcenter
> kde-base/khotkeys
> kde-base/kicker
> kde-base/kimagemapeditor
> kde-base/kjots
> kde-base/klinkstatus
> kde-base/klipper
> kde-base/kmail
> kde-base/kmenuedit
> kde-base/kmix
> kde-base/knetattach
> kde-base/knetworkconf
> kde-base/kolourpaint
> kde-base/kommander
> kde-base/konqueror
> kde-base/konsole
> kde-base/kontact
> kde-base/kopete
> kde-base/kppp
> kde-base/krdc
> kde-base/kreadconfig
> kde-base/krfb
> kde-base/kruler
> kde-base/kscd
> kde-base/kscreensaver
> kde-base/ksmserver
> kde-base/ksnapshot
> kde-base/kstart
> kde-base/ksysguard
> kde-base/ksystraycmd
> kde-base/ktimer
> kde-base/kuser
> kde-base/kweather
> kde-base/kwin
> kde-base/kxsldbg
> kde-base/libkcddb
> kde-base/libkdepim
> kde-base/libkonq
> kde-base/nsplugins
> ================================
>
> Other than the metas which I have marked with "<--Yes" I'm not sure I need the
> rest.  Shall I blow them away?
>
>    

I have a rather bloated kde install and this is mine:

root@smoker / # grep kde /var/lib/portage/world
kde-base/kde-meta
kde-base/kde-meta:3.5
kde-misc/youtube-servicemenu
root@smoker / #

You can always remove those things, run -p --depclean and add back with 
the -n option what you want to keep.

Dale

:-)  :-)

P. S.  Upgraded to Seamonkey 2.0 and I got to adjust a few settings 
here.  :/  It looks good on the screen but the quoting part . . . . sucks.

Re: [gentoo-user] FIXED: Re: KDE3 removal

[Neil Bothwick]

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

On Thu, 26 Nov 2009 20:59:24 +0000, Mick wrote:

> That's a good point ... over the years I have accumulated all sorts of 
> packages I am not sure I need (by forgetting to use --oneshot).  Should
> these be in there?

Do you use them, or does something else you use use them? In the former
case, they should be there, otherwise not.

Generally, anything starting with lib should not be in world.


-- 
Neil Bothwick

Keyboard: (n.) a device used by programmers to write software for a mouse
or joystick and by operators for playing games such as 'word processing.'

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

Re: [gentoo-user] FIXED: Re: KDE3 removal

[Alan McKinnon]

On Thursday 26 November 2009 22:59:24 Mick wrote:
> On Thursday 26 November 2009 19:20:26 Alan McKinnon wrote:
> > On Thursday 26 November 2009 19:34:34 James wrote:
> > > kde-4.3.1 went smooth, except
> > > for I have to manually removed all the kde-3.5 packages.
> > > It had kde-meta-3.5.10. Is there some syntax or a better
> > > method to insure all the kde-3.5.x packages are removed,
> > > without a manual sweep?
> >
> > grep kde /var/lib/portage/world
> > and eyeball the output. There should only be -meta packages, and
> > individual packages for which you have NOT installed the -meta package,
> > in there. vi the world file and remove the stuff that shouldn't be there,
> > then
> 
> That's a good point ... over the years I have accumulated all sorts of
> packages I am not sure I need (by forgetting to use --oneshot).  Should
>  these be in there?
> ================================
> kde-base/akregator
> kde-base/ark
> kde-base/drkonqi
> kde-base/kaddressbook
> kde-base/kappfinder
> kde-base/kate
> kde-base/kcalc
> kde-base/kcharselect
> kde-base/kcheckpass
> kde-base/kcminit
> kde-base/kcontrol
> kde-base/kcron
> kde-base/kdeadmin-meta  <--Yes
> kde-base/kdeartwork-emoticons
> kde-base/kdeartwork-iconthemes
> kde-base/kdeartwork-kscreensaver
> kde-base/kdeartwork-meta  <--Yes
> kde-base/kdeartwork-sounds
> kde-base/kdeartwork-styles
> kde-base/kdeartwork-wallpapers
> kde-base/kdebase-data
> kde-base/kdebase-kioslaves
> kde-base/kdebase-meta  <--Yes
> kde-base/kdebase-startkde
> kde-base/kdebugdialog
> kde-base/kdegraphics-meta  <--Yes
> kde-base/kdelibs
> kde-base/kdemultimedia-kioslaves
> kde-base/kdemultimedia-meta  <--Yes
> kde-base/kdenetwork-filesharing
> kde-base/kdenetwork-meta  <--Yes
> kde-base/kdepasswd
> kde-base/kdepim-meta  <--Yes
> kde-base/kdesu
> kde-base/kdeutils-meta  <--Yes
> kde-base/kdewebdev-meta  <--Yes
> kde-base/kdf
> kde-base/kdialog
> kde-base/kdm
> kde-base/kdnssd
> kde-base/kfilereplace
> kde-base/kfloppy
> kde-base/kgamma
> kde-base/kget
> kde-base/kghostview
> kde-base/kgpg
> kde-base/khelpcenter
> kde-base/khotkeys
> kde-base/kicker
> kde-base/kimagemapeditor
> kde-base/kjots
> kde-base/klinkstatus
> kde-base/klipper
> kde-base/kmail
> kde-base/kmenuedit
> kde-base/kmix
> kde-base/knetattach
> kde-base/knetworkconf
> kde-base/kolourpaint
> kde-base/kommander
> kde-base/konqueror
> kde-base/konsole
> kde-base/kontact
> kde-base/kopete
> kde-base/kppp
> kde-base/krdc
> kde-base/kreadconfig
> kde-base/krfb
> kde-base/kruler
> kde-base/kscd
> kde-base/kscreensaver
> kde-base/ksmserver
> kde-base/ksnapshot
> kde-base/kstart
> kde-base/ksysguard
> kde-base/ksystraycmd
> kde-base/ktimer
> kde-base/kuser
> kde-base/kweather
> kde-base/kwin
> kde-base/kxsldbg
> kde-base/libkcddb
> kde-base/libkdepim
> kde-base/libkonq
> kde-base/nsplugins
> ================================
> 
> Other than the metas which I have marked with "<--Yes" I'm not sure I need
>  the rest.  Shall I blow them away?

Hmmm. You need to do it the long way round:

1. Remove them from the world file
2. emerge -p --depclean
3. Eyeball the output paying attention to KDE4 apps that portage thinks it 
must remove. Decide if you want to keep them. If so, put them in world or 
emerge the larger -meta package they are part of
4. emerge -a --depclean and enter "y" only when you are finally happy with the 
list. Again, pay attention to version numbers.



-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: FIXED: Re: KDE3 removal

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:


> grep kde /var/lib/portage/world

only kde-meta in there

>emerge -a --depclean


yep, just making sure.... as I thought there might be a 
very special syntax to remove all kde 3.5.*

I used revdep-rebuild and emerge -uDNvp world to get the
list of 3.5 packages, and then just deleted them one by
one. Somehow there shlould be a cleaner way, as emerge -C
kde-meta (when only kde-meta-3.5 was installed) did not 
work on all packages. Even when I manually remove the 
"sub-meta" groups of kde-3.5 I still had packages in the groups
like games, I hand to manually remove. What a pain....


thx,
james

Re: [gentoo-user] Re: FIXED: Re: KDE3 removal

[Mick]

2009/11/26 James <wireless@tampabay.rr.com>:
> Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
>
>
>> grep kde /var/lib/portage/world
>
> only kde-meta in there
>
>>emerge -a --depclean
>
>
> yep, just making sure.... as I thought there might be a
> very special syntax to remove all kde 3.5.*
>
> I used revdep-rebuild and emerge -uDNvp world to get the
> list of 3.5 packages, and then just deleted them one by
> one. Somehow there shlould be a cleaner way, as emerge -C
> kde-meta (when only kde-meta-3.5 was installed) did not
> work on all packages. Even when I manually remove the
> "sub-meta" groups of kde-3.5 I still had packages in the groups
> like games, I hand to manually remove. What a pain....

Hmm, I thought that kweather, kate and kfloppy were brought in by some
meta or other.  It seems that I'll have to install these on their own?

kde-base/kweather
    selected: 4.3.1
   protected: none
     omitted: none

 kde-base/kate
    selected: 4.3.1
   protected: none
     omitted: none

 kde-base/kfloppy
    selected: 4.3.1
   protected: none
     omitted: none
-- 
Regards,
Mick

[gentoo-user] Re: FIXED: Re: KDE3 removal

[James]

Mick <michaelkintzios <at> gmail.com> writes:


> Hmm, I thought that kweather, kate and kfloppy were brought in by some
> meta or other.  It seems that I'll have to install these on their own?

Hello Mick,

I'm just not certain any more exactly which packages belong to
which meta(kde) package. I think they are added and dropped 
over the last few years, resulting in a dynamic grouping
or like those you mentioned, not being picked up by and of the
kde-meta packages.


Some time ago kde-meta ( the package that calls other kde-meta(sub
group packages) was to be done away with. Now, magically,
kde-meta is back, after the "Sets" solution seems to be
too cumbersome for those of us that want a simple and easy
method to install a bulk of kde packages.

Other than this '10,000' foot view, you'll have to get more
precise information from the gentoo kde devs or others,
as I just do not know......


You'd think there'd be a master listing of (kde-4) packages
and which one belong to which meta-package or what not;
if not a script to tool to reveal this information....


Let me know if you find a silver bullet (syntax) for discerning
what kde packages are grouped into which meta package or
not grouped at all..


hth,
James

Re: [gentoo-user] Re: FIXED: Re: KDE3 removal

[Alan McKinnon]

On Friday 27 November 2009 17:27:30 James wrote:
> Mick <michaelkintzios <at> gmail.com> writes:
> > Hmm, I thought that kweather, kate and kfloppy were brought in by some
> > meta or other.  It seems that I'll have to install these on their own?
> 
> Hello Mick,
> 
> I'm just not certain any more exactly which packages belong to
> which meta(kde) package. I think they are added and dropped
> over the last few years, resulting in a dynamic grouping
> or like those you mentioned, not being picked up by and of the
> kde-meta packages.

You fellows really need to read the full set of portage man pages. You sound 
like mechanics that don't know how spanners work.

The contents of packages is determined by upstream (KDE), not by the gentoo 
devs. Gentoo devs merely split the monolithic tarballs up into whatever apps 
the KDE devs say is inside it
 
To find out what is in a -meta package:

cat $PORTDIR/kde-base/*-meta/*ebuild 

There isn't a special tool to do this, much as there isn't a tool to tell you 
what stuff DEPENDs on say apache. There is a general tool, it's 
equery depends -a

> Some time ago kde-meta ( the package that calls other kde-meta(sub
> group packages) was to be done away with. 

You are mistaken. 

That has never ever been the case. The monolithic ebuilds have been done away 
with in favour of split ebuilds. This has been in planning for 2 years right 
from the beginning of the KDE-3.5 series

> Now, magically,
> kde-meta is back, after the "Sets" solution seems to be
> too cumbersome for those of us that want a simple and easy
> method to install a bulk of kde packages.

Citation please :-)

Zac has never to my knowledge said that sets are too cumbersome for regular 
people. Sets are not yet in stable portage because he wants the feature to be 
tested more. Therefore sets cannot be exposed in the portage tree. That's why 
defined sets are only distributed in the overlays, not in the tree.


> Other than this '10,000' foot view, you'll have to get more
> precise information from the gentoo kde devs or others,
> as I just do not know......

To find out what depends on kate, kweather and kfloppy, use the correct 
portage tool:

alan@nazgul ~ $ equery depends -a kate
 * Searching for kate ...
kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
kde-base/kdesdk-meta-4.3.3 (!kdeprefix ? >=kde-base/kate-4.3.3[-kdeprefix])
                           (kdeprefix ? >=kde-base/kate-4.3.3:4.3[kdeprefix])

alan@nazgul ~ $ equery depends -a kweather
 * Searching for kweather ...
kde-base/kdetoys-meta-4.3.1 (>=kde-base/kweather-4.3.1:4.3[kdeprefix=])
kde-base/kdetoys-meta-4.3.3 (!kdeprefix ? >=kde-base/kweather-4.3.3[-
kdeprefix])
                            (kdeprefix ? >=kde-
base/kweather-4.3.3:4.3[kdeprefix])

alan@nazgul ~ $ equery depends -a kfloppy
 * Searching for kfloppy ...
kde-base/kdeutils-meta-4.3.1 (floppy ? >=kde-
base/kfloppy-4.3.1:4.3[kdeprefix=])
kde-base/kdeutils-meta-4.3.3 (floppy & !kdeprefix ? >=kde-base/kfloppy-4.3.3[-
kdeprefix])
                             (floppy & kdeprefix ? >=kde-
base/kfloppy-4.3.3:4.3[kdeprefix])


So kate DEPENDS on kdesdk (it's a dev tool, emerge it individually if you just 
want the editor)
kweather DEPENDS on kde-toys
kfloppy DEPENDS on kdeutils iff USE=floppy

> You'd think there'd be a master listing of (kde-4) packages
> and which one belong to which meta-package or what not;
> if not a script to tool to reveal this information....

There is. See above.

> Let me know if you find a silver bullet (syntax) for discerning
> what kde packages are grouped into which meta package or
> not grouped at all..

This is Unix. We use grep, sed and awk to find stuff.

Much faster than just about anything else...

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: FIXED: Re: KDE3 removal

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2563 bytes --]

On Friday 27 November 2009 15:53:41 Alan McKinnon wrote:
> On Friday 27 November 2009 17:27:30 James wrote:
> > Mick <michaelkintzios <at> gmail.com> writes:
> > > Hmm, I thought that kweather, kate and kfloppy were brought in by some
> > > meta or other.  It seems that I'll have to install these on their own?
> >
> > Hello Mick,
> >
> > I'm just not certain any more exactly which packages belong to
> > which meta(kde) package. I think they are added and dropped
> > over the last few years, resulting in a dynamic grouping
> > or like those you mentioned, not being picked up by and of the
> > kde-meta packages.
> 
> You fellows really need to read the full set of portage man pages. You
>  sound like mechanics that don't know how spanners work.

I'm sure there's a spanner thrown somewhere in the works ...

> The contents of packages is determined by upstream (KDE), not by the gentoo
> devs. Gentoo devs merely split the monolithic tarballs up into whatever
>  apps the KDE devs say is inside it
> 
> To find out what is in a -meta package:
> 
> cat $PORTDIR/kde-base/*-meta/*ebuild
> 
> There isn't a special tool to do this, much as there isn't a tool to tell
>  you what stuff DEPENDs on say apache. There is a general tool, it's
> equery depends -a
[snip ...]

> To find out what depends on kate, kweather and kfloppy, use the correct
> portage tool:
> 
> alan@nazgul ~ $ equery depends -a kate
>  * Searching for kate ...
> kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> kde-base/kdesdk-meta-4.3.3 (!kdeprefix ? >=kde-base/kate-4.3.3[-kdeprefix])
>                            (kdeprefix ?
>  >=kde-base/kate-4.3.3:4.3[kdeprefix])

OK, but I am getting this much - slightly different to yours above:

# equery depends -a kate
[ Searching for packages depending on kate... ]
kde-base/kde-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])

Now, fair enough, I do not have kde-base/kde-meta installed, so nothing wants 
to pull back in kate when I update world.

> > Let me know if you find a silver bullet (syntax) for discerning
> > what kde packages are grouped into which meta package or
> > not grouped at all..
> 
> This is Unix. We use grep, sed and awk to find stuff.
> 
> Much faster than just about anything else...

Right, but only if your regex-fu is good enough.  Mine is rather pathetic ... 
:-(

Grateful for all help received to pick up the right spanner.  ;-)
-- 
Regards,
Mick

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

Re: [gentoo-user] Re: FIXED: Re: KDE3 removal

[Alan McKinnon]

On Saturday 28 November 2009 02:01:22 Mick wrote:
> > To find out what depends on kate, kweather and kfloppy, use the correct
> > portage tool:
> > 
> > alan@nazgul ~ $ equery depends -a kate
> >  * Searching for kate ...
> > kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> > kde-base/kdesdk-meta-4.3.3 (!kdeprefix ?
> > >=kde-base/kate-4.3.3[-kdeprefix]) (kdeprefix ?
> >  >=kde-base/kate-4.3.3:4.3[kdeprefix])
> 
> OK, but I am getting this much - slightly different to yours above:
> 
> # equery depends -a kate
> [ Searching for packages depending on kate... ]
> kde-base/kde-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> 
> Now, fair enough, I do not have kde-base/kde-meta installed, so nothing
>  wants  to pull back in kate when I update world.
> 

That's normal. The pre-defined sets in kde-testing overlay explicitly list 
kate in the @kde set for that reason.

I suppose one could make several useful -meta packages DEPEND on kate, as many 
users want kate and do not want the entire kdesdk package. But that causes the 
same app to appear in more than one -meta package and the devs seem to want to 
avoid that - there is a strict one-to-one mapping between what the -meta 
packages install and what is shipped in the upstream tarballs by KDE


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: FIXED: Re: KDE3 removal

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1771 bytes --]

On Saturday 28 November 2009 13:22:14 Alan McKinnon wrote:
> On Saturday 28 November 2009 02:01:22 Mick wrote:
> > > To find out what depends on kate, kweather and kfloppy, use the correct
> > > portage tool:
> > >
> > > alan@nazgul ~ $ equery depends -a kate
> > >  * Searching for kate ...
> > > kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> > > kde-base/kdesdk-meta-4.3.3 (!kdeprefix ?
> > >
> > > >=kde-base/kate-4.3.3[-kdeprefix]) (kdeprefix ?
> > > >
> > >  >=kde-base/kate-4.3.3:4.3[kdeprefix])
> >
> > OK, but I am getting this much - slightly different to yours above:
> >
> > # equery depends -a kate
> > [ Searching for packages depending on kate... ]
> > kde-base/kde-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> > kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> >
> > Now, fair enough, I do not have kde-base/kde-meta installed, so nothing
> >  wants  to pull back in kate when I update world.
> 
> That's normal. The pre-defined sets in kde-testing overlay explicitly list
> kate in the @kde set for that reason.
> 
> I suppose one could make several useful -meta packages DEPEND on kate, as
>  many users want kate and do not want the entire kdesdk package. But that
>  causes the same app to appear in more than one -meta package and the devs
>  seem to want to avoid that - there is a strict one-to-one mapping between
>  what the -meta packages install and what is shipped in the upstream
>  tarballs by KDE

Sorry I'm being rather dense with this ... are you saying that the DEPENDs 
listed when you run 'equery depends -a kate' are different to mine because you 
are running KDE4 from KDE-testing overlay, while I am running stable portage?
-- 
Regards,
Mick

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

Re: [gentoo-user] Re: FIXED: Re: KDE3 removal

[Alan McKinnon]

On Saturday 28 November 2009 21:32:28 Mick wrote:
> > I suppose one could make several useful -meta packages DEPEND on kate, as
> >  many users want kate and do not want the entire kdesdk package. But that
> >  causes the same app to appear in more than one -meta package and the
> > devs seem to want to avoid that - there is a strict one-to-one mapping
> > between what the -meta packages install and what is shipped in the
> > upstream tarballs by KDE
> 
> Sorry I'm being rather dense with this ... are you saying that the DEPENDs 
> listed when you run 'equery depends -a kate' are different to mine because
>  you  are running KDE4 from KDE-testing overlay, while I am running stable
>  portage?
> 

No, the contents of the -meta packages are pretty much the same between the 
overlay and the official tree (apart from new apps added in the latest KDE 
snapshots, and other minor things that get dropped in the new branch of 
course).

The kde-testing overlay provides a collection of sets which the portage tree 
does not do. The main set explicitly includes kate because it's part of kdesdk 
and it's a bit rich to expect all users to install the entire dev suite just 
to get a gui text editor.

The official tree has the same situation:

# grep kate /var/portage/kde-base/*-meta*/*4.3.3.ebuild
/var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild:   $(add_kdebase_dep 
kate)
/var/portage/kde-base/kdesdk-meta/kdesdk-meta-4.3.3.ebuild:     
$(add_kdebase_dep kate)

# cat /var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild
...
RDEPEND="
        $(add_kdebase_dep kate)
        $(add_kdebase_dep kdeadmin-meta)
...

To give kate to users, it was added to kde-meta, and it's the only explicit 
DEPEND in the ebuild, everything else is the smaller -meta packages.

To get kate, you must do one of:
1. emerge kde-meta (or the @kde set)
2. emerge kdesdk (or the @kdesdk set)
3. emerge kate

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: FIXED: Re: KDE3 removal

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2168 bytes --]

On Saturday 28 November 2009 19:42:33 Alan McKinnon wrote:
> On Saturday 28 November 2009 21:32:28 Mick wrote:
> > > I suppose one could make several useful -meta packages DEPEND on kate,
> > > as many users want kate and do not want the entire kdesdk package. But
> > > that causes the same app to appear in more than one -meta package and
> > > the devs seem to want to avoid that - there is a strict one-to-one
> > > mapping between what the -meta packages install and what is shipped in
> > > the upstream tarballs by KDE
> >
> > Sorry I'm being rather dense with this ... are you saying that the
> > DEPENDs listed when you run 'equery depends -a kate' are different to
> > mine because you  are running KDE4 from KDE-testing overlay, while I am
> > running stable portage?
> 
> No, the contents of the -meta packages are pretty much the same between the
> overlay and the official tree (apart from new apps added in the latest KDE
> snapshots, and other minor things that get dropped in the new branch of
> course).
> 
> The kde-testing overlay provides a collection of sets which the portage
>  tree does not do. The main set explicitly includes kate because it's part
>  of kdesdk and it's a bit rich to expect all users to install the entire
>  dev suite just to get a gui text editor.
> 
> The official tree has the same situation:
> 
> # grep kate /var/portage/kde-base/*-meta*/*4.3.3.ebuild
> /var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild:   $(add_kdebase_dep
> kate)
> /var/portage/kde-base/kdesdk-meta/kdesdk-meta-4.3.3.ebuild:
> $(add_kdebase_dep kate)
> 
> # cat /var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild
> ...
> RDEPEND="
>         $(add_kdebase_dep kate)
>         $(add_kdebase_dep kdeadmin-meta)
> ...
> 
> To give kate to users, it was added to kde-meta, and it's the only explicit
> DEPEND in the ebuild, everything else is the smaller -meta packages.
> 
> To get kate, you must do one of:
> 1. emerge kde-meta (or the @kde set)
> 2. emerge kdesdk (or the @kdesdk set)
> 3. emerge kate

Thank you kindly for persevering - the logic is clear to me now.  :-)

-- 
Regards,
Mick

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

[gentoo-user] Re: FIXED: Re: KDE3 removal

[Jörg Schaible]

Alan McKinnon wrote:

> On Thursday 26 November 2009 19:34:34 James wrote:
>> kde-4.3.1 went smooth, except
>> for I have to manually removed all the kde-3.5 packages.
>> It had kde-meta-3.5.10. Is there some syntax or a better
>> method to insure all the kde-3.5.x packages are removed,
>> without a manual sweep?
>> 
> 
> grep kde /var/lib/portage/world
> and eyeball the output. There should only be -meta packages, and
> individual packages for which you have NOT installed the -meta package, in
> there. vi the world file and remove the stuff that shouldn't be there,
> then
> 
> emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean
> 

as alternative simply append to all kde-base/* packages in world :4.3 and do
then a depclean ;-)

- Jörg

Re: [gentoo-user] Re: FIXED: Re: KDE3 removal

[Alan McKinnon]

On Friday 27 November 2009 23:07:25 Jörg Schaible wrote:
> Alan McKinnon wrote:
> > On Thursday 26 November 2009 19:34:34 James wrote:
> >> kde-4.3.1 went smooth, except
> >> for I have to manually removed all the kde-3.5 packages.
> >> It had kde-meta-3.5.10. Is there some syntax or a better
> >> method to insure all the kde-3.5.x packages are removed,
> >> without a manual sweep?
> >
> > grep kde /var/lib/portage/world
> > and eyeball the output. There should only be -meta packages, and
> > individual packages for which you have NOT installed the -meta package,
> > in there. vi the world file and remove the stuff that shouldn't be there,
> > then
> >
> > emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean
> 
> as alternative simply append to all kde-base/* packages in world :4.3 and
>  do then a depclean ;-)

Which promptly defeats the ENTIRE purpose of a world file and -meta packages.

If that's how you want to admin your box, can I recommend you switch to 
sabayon instead?

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: Re: FIXED: Re: KDE3 removal

[Jörg Schaible]

Alan McKinnon wrote:

> On Friday 27 November 2009 23:07:25 Jörg Schaible wrote:
>> Alan McKinnon wrote:
>> > On Thursday 26 November 2009 19:34:34 James wrote:
>> >> kde-4.3.1 went smooth, except
>> >> for I have to manually removed all the kde-3.5 packages.
>> >> It had kde-meta-3.5.10. Is there some syntax or a better
>> >> method to insure all the kde-3.5.x packages are removed,
>> >> without a manual sweep?
>> >
>> > grep kde /var/lib/portage/world
>> > and eyeball the output. There should only be -meta packages, and
>> > individual packages for which you have NOT installed the -meta package,
>> > in there. vi the world file and remove the stuff that shouldn't be
>> > there, then
>> >
>> > emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean
>> 
>> as alternative simply append to all kde-base/* packages in world :4.3 and
>>  do then a depclean ;-)
> 
> Which promptly defeats the ENTIRE purpose of a world file and -meta
> packages.

a) I've never used the meta packages, but selected my KDE apps on purpose
b) it's a lot easier this way to get rid of the KDE 3 stuff, however you
should get drop of the slot again after depclean has been finished

> If that's how you want to admin your box,

I am using long enough Gentoo that I remember very well the times when
portage destroyed the world file completely. And regenworld put *anything*
into world at that time. Therefore I know very well, what should be in this
file and what not. There's no magic.

> can I recommend you switch to 
> sabayon instead?

ROFL! So, you mean, if users get too smart, Gentoo is no longer their
distribution? Don't be silly.

- Jörg

Re: [gentoo-user] Re: Re: FIXED: Re: KDE3 removal

[Alan McKinnon]

On Saturday 28 November 2009 13:59:38 Jörg Schaible wrote:
> Alan McKinnon wrote:
> > On Friday 27 November 2009 23:07:25 Jörg Schaible wrote:
> >> Alan McKinnon wrote:
> >> > On Thursday 26 November 2009 19:34:34 James wrote:
> >> >> kde-4.3.1 went smooth, except
> >> >> for I have to manually removed all the kde-3.5 packages.
> >> >> It had kde-meta-3.5.10. Is there some syntax or a better
> >> >> method to insure all the kde-3.5.x packages are removed,
> >> >> without a manual sweep?
> >> >
> >> > grep kde /var/lib/portage/world
> >> > and eyeball the output. There should only be -meta packages, and
> >> > individual packages for which you have NOT installed the -meta
> >> > package, in there. vi the world file and remove the stuff that
> >> > shouldn't be there, then
> >> >
> >> > emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean
> >>
> >> as alternative simply append to all kde-base/* packages in world :4.3
> >> and do then a depclean ;-)
> >
> > Which promptly defeats the ENTIRE purpose of a world file and -meta
> > packages.
> 
> a) I've never used the meta packages, but selected my KDE apps on purpose

You missed the part where the user clearly states earlier that he DOES use 
-meta packages. With that in mind, any advice you give should be aligned to 
the fact that he is a -meta user

> b) it's a lot easier this way to get rid of the KDE 3 stuff, however you
> should get drop of the slot again after depclean has been finished

How is it easier? You have to maintain the SLOTs in world yourself because the 
instant you do that portage will not automagically offer to upgrade anymore 
(upgrades within the same slot excepted). And --depclean will NOT adjust your 
SLOTs in world when it's finished. I can't really make sense of your last 
sentence but that is what you seem to imply


> > If that's how you want to admin your box,
> 
> I am using long enough Gentoo that I remember very well the times when
> portage destroyed the world file completely. 

That was long ago and no longer applicable. That bug in portage got fixed, so 
a behaviour on your part to compensate for a bug that is not there is outdated 
behaviour.

> And regenworld put *anything*
> into world at that time. Therefore I know very well, what should be in this
> file and what not. There's no magic.

Yes, the only things in world are packages you want that are not dependencies 
of something else already in world. You are advising the user to put the 
dependencies of -meta packages into world when the -meta package is already 
there.

And that is plain silly
 
> > can I recommend you switch to
> > sabayon instead?
> 
> ROFL! So, you mean, if users get too smart, Gentoo is no longer their
> distribution? Don't be silly.

Erm, you should read the whole thread and realise the bits you missed - the 
bits that make your statements nonsensical



-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: Re: Re: FIXED: Re: KDE3 removal

[Jörg Schaible]

Alan McKinnon wrote:

> On Saturday 28 November 2009 13:59:38 Jörg Schaible wrote:
>> Alan McKinnon wrote:
>> > On Friday 27 November 2009 23:07:25 Jörg Schaible wrote:
>> >> Alan McKinnon wrote:
>> >> > On Thursday 26 November 2009 19:34:34 James wrote:
>> >> >> kde-4.3.1 went smooth, except
>> >> >> for I have to manually removed all the kde-3.5 packages.
>> >> >> It had kde-meta-3.5.10. Is there some syntax or a better
>> >> >> method to insure all the kde-3.5.x packages are removed,
>> >> >> without a manual sweep?
>> >> >
>> >> > grep kde /var/lib/portage/world
>> >> > and eyeball the output. There should only be -meta packages, and
>> >> > individual packages for which you have NOT installed the -meta
>> >> > package, in there. vi the world file and remove the stuff that
>> >> > shouldn't be there, then
>> >> >
>> >> > emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a
>> >> > --depclean
>> >>
>> >> as alternative simply append to all kde-base/* packages in world :4.3
>> >> and do then a depclean ;-)
>> >
>> > Which promptly defeats the ENTIRE purpose of a world file and -meta
>> > packages.
>> 
>> a) I've never used the meta packages, but selected my KDE apps on purpose
> 
> You missed the part where the user clearly states earlier that he DOES use
> -meta packages. With that in mind, any advice you give should be aligned
> to the fact that he is a -meta user
>
>> b) it's a lot easier this way to get rid of the KDE 3 stuff, however you
>> should get drop of the slot again after depclean has been finished
> 
> How is it easier? You have to maintain the SLOTs in world yourself because
> the instant you do that portage will not automagically offer to upgrade
> anymore (upgrades within the same slot excepted). And --depclean will NOT
> adjust your SLOTs in world when it's finished. I can't really make sense
> of your last sentence but that is what you seem to imply

Yes, that's what I've said. Drop the slot again after depclean has finished.
Exactly because of the upgrades.

>> > If that's how you want to admin your box,
>> 
>> I am using long enough Gentoo that I remember very well the times when
>> portage destroyed the world file completely.
> 
> That was long ago and no longer applicable. That bug in portage got fixed,
> so a behaviour on your part to compensate for a bug that is not there is
> outdated behaviour.
>
>> And regenworld put *anything*
>> into world at that time. Therefore I know very well, what should be in
>> this file and what not. There's no magic.
> 
> Yes, the only things in world are packages you want that are not
> dependencies of something else already in world. You are advising the user
> to put the dependencies of -meta packages into world

No. I adviced him to add :4.3 to all kde-base/* packages that *are* in
world. 

> when the -meta 
> package is already there.

It does not matter in this case if the package is -meta or not.

> 
> And that is plain silly
>  
>> > can I recommend you switch to
>> > sabayon instead?
>> 
>> ROFL! So, you mean, if users get too smart, Gentoo is no longer their
>> distribution? Don't be silly.
> 
> Erm, you should read the whole thread and realise the bits you missed -
> the bits that make your statements nonsensical

All I did, was offering an alternative method to get rid of KDE 3 using
depclean without the need to identify every package individually.

Feel free to ignore it.

- Jörg