[gentoo-user] Best route forward?
I installed KDE yesterday via emerge kde -vuD, and just remembered today about kde-meta, which installs a lot more. In running emerge kde-meta -vuD, I get 250 new packages, and 245 blocks, with 1 upgrade. What is the _best_ path forward? Should I just stick with my current build of kde? Or is there an easy way to remove all the blocks and then push in kde-meta? Is it worth it? TIA, Ben -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Best route forward?
BRM wrote: I installed KDE yesterday via emerge kde -vuD, and just remembered today about kde-meta, which installs a lot more. In running emerge kde-meta -vuD, I get 250 new packages, and 245 blocks, with 1 upgrade. What is the _best_ path forward? Should I just stick with my current build of kde? Or is there an easy way to remove all the blocks and then push in kde-meta? Is it worth it? If you want to do the meta, you can unmerge kde, and then do an emerge --depclean. -- Randy Barlow http://electronsweatshop.com -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Best route forward?
On Wed, 2 Jan 2008 13:40:11 -0800 (PST) BRM [EMAIL PROTECTED] wrote: I installed KDE yesterday via emerge kde -vuD, and just remembered today about kde-meta, which installs a lot more. In running emerge kde-meta -vuD, I get 250 new packages, and 245 blocks, with 1 upgrade. What is the _best_ path forward? Should I just stick with my current build of kde? Or is there an easy way to remove all the blocks and then push in kde-meta? Is it worth it? TIA, Ben -- [EMAIL PROTECTED] mailing list There are two kind of kde installs, or three, if you ask me. You can install kde. That will pull into your system the big packages just like they are released by the kde team. That means, several big monoliths, like kdebase, kdenetwork, kdegraphics and so on. You can install using split ebuilds as well. For example, instead of installing kdebase, you only need a couple of programs. So, you just install, let's say, konqueror and konsole, instead of kdebase. Of course, you can install all the pieces of kdebase using split ebuilds, and both installs would be equivalent. The downside is that you would need to install lots of small packages, instead of a big monolithic one. That way you save some space, but, what's more important for me, you save hours of compilation for things that you will never use. The other solution is to use meta-ebuilds. For example, you can install kdebase-meta, instead of kdebase. This is kind of an hybrid approach. When you emerge kdebase-meta, you end with the same that you would get by installing kdebase, but it will be done using split ebuilds. The good thing is that you will still get the modulatiry, without having to install all the split ebuilds by hand, because the meta-package pulls all of the components of kdebase but using split ebuilds as dependencies. So, you already know why you are getting that big list of packages to install: you are not going to get anything more if you install those packages, because they are a split version of the big kde packages you already installed. The blockers are simple to understand: you can't have kdebase and kdebase-meta installed at the same time. They are equivalent, it would be a nonsense anyway. So, all the components of a given meta- package, block the matching monolithic package. That way portage can prevent weird things like the one you were trying to do :) I hope it made sense, if not, ask for clarification. Regards. -- Jesús Guerrero [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Best route forward?
On Mittwoch, 2. Januar 2008, BRM wrote: I installed KDE yesterday via emerge kde -vuD, and just remembered today about kde-meta, which installs a lot more. In running emerge kde-meta -vuD, I get 250 new packages, and 245 blocks, with 1 upgrade. What is the _best_ path forward? Should I just stick with my current build of kde? Or is there an easy way to remove all the blocks and then push in kde-meta? Is it worth it? TIA, Ben kde and kde-meta install the same apps. One is in monolith packages, the other one uses the split ebuilds. If you install everything, monolith is a lot faster. But some important useflags are only used and the features enabled with split ebuilds (g). Like kdenetworkkopete. With kdenetwork kopete emerges without the history plugin, even if all useflags are set (which sucks greatly). With split ebuilds, kopete gets its history plugin (there is no logic behind this - but the devs decided it this way...). You don't have to unmerge kde first. You can do it in a more 'gradual' way. For example: first unmerge kdenetwork, then emerge kdenetwork-meta. Unmerge kdebase, emerge kdebase-meta and so on. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Best route forward?
Jesús Guerrero wrote: There are two kind of kde installs, or three, if you ask me. You can install kde. That will pull into your system the big packages just like they are released by the kde team. That means, several big monoliths, like kdebase, kdenetwork, kdegraphics and so on. You can install using split ebuilds as well. For example, instead of installing kdebase, you only need a couple of programs. So, you just install, let's say, konqueror and konsole, instead of kdebase. Of course, you can install all the pieces of kdebase using split ebuilds, and both installs would be equivalent. The downside is that you would need to install lots of small packages, instead of a big monolithic one. That way you save some space, but, what's more important for me, you save hours of compilation for things that you will never use. The other solution is to use meta-ebuilds. For example, you can install kdebase-meta, instead of kdebase. This is kind of an hybrid approach. When you emerge kdebase-meta, you end with the same that you would get by installing kdebase, but it will be done using split ebuilds. The good thing is that you will still get the modulatiry, without having to install all the split ebuilds by hand, because the meta-package pulls all of the components of kdebase but using split ebuilds as dependencies. So, you already know why you are getting that big list of packages to install: you are not going to get anything more if you install those packages, because they are a split version of the big kde packages you already installed. The blockers are simple to understand: you can't have kdebase and kdebase-meta installed at the same time. They are equivalent, it would be a nonsense anyway. So, all the components of a given meta- package, block the matching monolithic package. That way portage can prevent weird things like the one you were trying to do :) I hope it made sense, if not, ask for clarification. Regards. Could he just unmerge kdebase then emerge kdebase-meta? I don't mean to uninstall all the KDE stuff he has already compiled but just the little one that pulls in all the other packages. Dale :-) :-) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Best route forward?
--- Jesús Guerrero [EMAIL PROTECTED] wrote: On Wed, 2 Jan 2008 13:40:11 -0800 (PST) BRM [EMAIL PROTECTED] wrote: What is the _best_ path forward? Should I just stick with my current build of kde? Or is there an easy way to remove all the blocks and then push in kde-meta? Is it worth it? There are two kind of kde installs, or three, if you ask me. You can install kde. That will pull into your system the big packages just like they are released by the kde team. That means, several big monoliths, like kdebase, kdenetwork, kdegraphics and so on. You can install using split ebuilds as well. For example, instead of installing kdebase, you only need a couple of programs. So, you just install, let's say, konqueror and konsole, instead of kdebase. Of course, you can install all the pieces of kdebase using split ebuilds, and both installs would be equivalent. The downside is that you would need to install lots of small packages, instead of a big monolithic one. That way you save some space, but, what's more important for me, you save hours of compilation for things that you will never use. The other solution is to use meta-ebuilds. For example, you can install kdebase-meta, instead of kdebase. This is kind of an hybrid approach. When you emerge kdebase-meta, you end with the same that you would get by installing kdebase, but it will be done using split ebuilds. The good thing is that you will still get the modulatiry, without having to install all the split ebuilds by hand, because the meta-package pulls all of the components of kdebase but using split ebuilds as dependencies. So, you already know why you are getting that big list of packages to install: you are not going to get anything more if you install those packages, because they are a split version of the big kde packages you already installed. The blockers are simple to understand: you can't have kdebase and kdebase-meta installed at the same time. They are equivalent, it would be a nonsense anyway. So, all the components of a given meta- package, block the matching monolithic package. That way portage can prevent weird things like the one you were trying to do :) I hope it made sense, if not, ask for clarification. Thanks, and yes it does. I haven't vested much in the install yet, and the more modular approach seems nicer to me, so I think I'll switch it over now before its too costly. Thanks! Ben -- [EMAIL PROTECTED] mailing list
