Re: [gentoo-user] Re: FIXED: Re: KDE3 removal
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: a...@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
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: a...@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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: FIXED: Re: KDE3 removal
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
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: FIXED: Re: KDE3 removal
2009/11/26 James wirel...@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
Re: [gentoo-user] Re: FIXED: Re: KDE3 removal
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: a...@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]) a...@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]) a...@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
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
Re: [gentoo-user] Re: FIXED: Re: KDE3 removal
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: a...@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 signature.asc Description: This is a digitally signed message part.
