| View previous topic :: View next topic |
| Author |
Message |
IntergalacticWalrus
Guru
Joined: 07 Jan 2003
Posts: 513
Location: Montreal QC (Canada)
|
 Posted: Sat Apr 01, 2006 12:31 am Post subject: KDE split/monolithic interoperability? |
 |
|
OK, first of all the KDE Split Ebuilds HOWTO says:
| Quote: | Split and monolithic ebuild interoperability
Split and monolithic ebuilds can be mixed freely. The only restriction is that a monolithic ebuild can't be installed at the same time as a split ebuild deriving from it. There are blocking deps in the ebuilds that enforce this, so you can do anything emerge allows you to do.
Ordinarily, however, there's no reason to use such a mixed configuration. In fact, except for special cases like very slow-compiling boxes (mips), you should use the split ebuilds for all your needs.
The split ebuilds are also the default ebuilds. This means that when some other ebuild depends on a KDE application, it will want to install a split ebuild. However, the matching monolithic ebuild will also satisfy that dep, so you can emerge the monolithic ebuild manually and then emerge the ebuild that depended on it. |
When updating to KDE 3.5.2 I'd like to finally do the migration to split ebuilds. However I would prefer to keep the monolithic kdebase because I use pretty much everything in it. The quoted section above seems to imply that monolithic and split builds can be mixed and Portage will correctly manage the dependencies, however from what I've tried so far it doesn't appear to work. For example, when I try to emerge, say, kbstateapplet, which depends on kcontrol from kdebase, I get the following output:
| Code: | $ emerge -p kbstateapplet
These are the packages that would be merged, in order:
Calculating dependencies... done!
[blocks B ] =kde-base/kdebase-3.5* (is blocking kde-base/khotkeys-3.5.1)
[blocks B ] =kde-base/kdebase-3.5* (is blocking kde-base/libkonq-3.5.2)
[blocks B ] =kde-base/kdebase-3.5* (is blocking kde-base/kdebase-data-3.5.2)
[blocks B ] =kde-base/kdebase-3.5* (is blocking kde-base/kicker-3.5.2)
[blocks B ] =kde-base/kdebase-3.5* (is blocking kde-base/kdesu-3.5.0)
[blocks B ] =kde-base/kdebase-3.5* (is blocking kde-base/kcontrol-3.5.2)
[blocks B ] =kde-base/kdebase-3.5* (is blocking kde-base/khelpcenter-3.5.2)
[blocks B ] =kde-base/kdebase-3.5* (is blocking kde-base/kcminit-3.5.0)
[ebuild N ] kde-base/khotkeys-3.5.1 USE="arts kdeenablefinal kdexdeltas xinerama -debug"
[ebuild N ] kde-base/libkonq-3.5.2 USE="arts kdeenablefinal kdexdeltas xinerama -debug"
[ebuild N ] kde-base/kdebase-data-3.5.2 USE="arts kdeenablefinal kdexdeltas xinerama -debug"
[ebuild N ] kde-base/kicker-3.5.2 USE="arts kdeenablefinal kdexdeltas xcomposite xinerama -debug"
[ebuild N ] kde-base/kdesu-3.5.0 USE="arts kdeenablefinal kdexdeltas xinerama -debug"
[ebuild N ] kde-base/khelpcenter-3.5.2 USE="arts kdeenablefinal kdexdeltas xinerama -debug"
[ebuild N ] kde-base/kcminit-3.5.0 USE="arts kdeenablefinal kdexdeltas xinerama -debug"
[ebuild N ] kde-base/kcontrol-3.5.2 USE="arts kdeenablefinal kdexdeltas logitech-mouse opengl ssl xinerama -debug -ieee1394"
[ebuild N ] kde-base/kbstateapplet-3.5.2 USE="arts kdeenablefinal kdexdeltas xinerama -debug" |
It appears Portage wants to install the split ebuilds from kdebase that kbstateapplet depends upon, even though the monolithic kdebase-3.5.2 is installed, and naturally the blocking deps kick in. Have I misunderstood the HOWTO or something? |
|
| Back to top |
|
 |
BitJam
Advocate
Joined: 12 Aug 2003
Posts: 2508
Location: Silver City, NM
|
| Posted: Sat Apr 01, 2006 1:23 am Post subject: |
|
|
Don't mix monolithic and split ebuilds unless you have a specific reason to do so.
Instead, use the xxx-meta ebuild where you would "normally" want to be using a monolithic ebuild.
Personally, I find the meta ebuilds kind of a drag since they are totally an all or nothing proposition. If you think that someday you may want to unmerge one of the components of a meta ebuild then you are better off getting a list of the components of the meta ebuild (either from the ebuild file directly or from editing the output of emerge -p xxx-meta) and then emerging all of the components. You can easily emerge every package listed in a file by doing: | Code: | | emerge -pv $(<package_list) |
where package_list is the file containing the list of packages to emerge. |
|
| Back to top |
|
|
IntergalacticWalrus
Guru
Joined: 07 Jan 2003
Posts: 513
Location: Montreal QC (Canada)
|
| Posted: Sat Apr 01, 2006 1:26 am Post subject: |
|
|
But the HOWTO says it should work...
I really don't want to emerge kdebase-meta. It's going to take forever to compile everything in kdebase seperately. |
|
| Back to top |
|
|
BitJam
Advocate
Joined: 12 Aug 2003
Posts: 2508
Location: Silver City, NM
|
| Posted: Sat Apr 01, 2006 2:34 am Post subject: |
|
|
I read the instructions differently than you do. I see: | Quote: | How to upgrade from the monolithic to the split ebuilds
If you have the KDE 3.4.x monolithic ebuilds installed, you must unmerge them before emerging the split ebuilds. However, this process can be done for each monolithic ebuild in turn; you don't have to unmerge all of KDE at once.
If you're in doubt, remember there are blocking deps in place between each monolithic ebuild and the split ebuilds derived from it. Portage won't allow an illegal state to be created, so any emerge or unmerge it allows is OK. |
Or even from your own quote: | Quote: | | Ordinarily, however, there's no reason to use such a mixed configuration. In fact, except for special cases like very slow-compiling boxes (mips), you should use the split ebuilds for all your needs. |
My reading of the instructions says "don't mix unless you really have to.".
On the other hand, I can clearly see your reading of the HOWTO with a very strict interpretation of the phrase "a split ebuild deriving from [a monolithic ebuild]" meaning only those ebuilds that are part of the corresponding xxx-meta ebuild.
I don't know why this isn't working for you. Perhaps the writers of the HOWTO had a more liberal meaning of "derived from". Maybe mixing only works in the stable 3.4.x branch and not for 3.5.x. Maybe some of the split ebuilds in kdebase-meta have been upgraded due to bug fixes but the monolithic kdebase has not yet been upgraded to include the latest and greatest so it can't fulfill the dependencies.
I am really no expert in this, and I can't say for sure that there is no way around this problem but I think the easiest thing for you in the long term will be to just bite the bullet and unmerge kdebase and emerge kdebase-meta overnight.
Another tip: Before doing any more kde emerging, emerge and enable ccache. It will let you cache the output of compiles during emerges. It won't help immediately but if you had it enabled when you emerged kdebase it is quite possible that the emerge of kdebase-meta would go extremely fast (assuming it was able to use the cached results). |
|
| Back to top |
|
|
IntergalacticWalrus
Guru
Joined: 07 Jan 2003
Posts: 513
Location: Montreal QC (Canada)
|
| Posted: Sat Apr 01, 2006 4:55 am Post subject: |
|
|
I managed to have everything coexist by modifying the offending ebuilds and change "deprange" to "deprange-dual" (turned out to be not much work since I only had one of them: kate-plugins). Apparently not all of them were written correctly, which is why the mixed dependencies were not resolved. I'll file a bug on that later.
Your quoting of the HOWTO talks about switching from monolithic to splitted. It didn't mention mixing.
As for the whole "there's no reason", I'm sorry but I don't understand why one would say that. Seperating a KDE package in Gentoo means lots and lots of redundant autoconf/automake overhead (not to mention plain Portage overhead). I do use ccache but it is not of much use in this situation. I have better things to do with my CPU time than repeating the same stupid configuration phase on everything . Split ebuilds are great when you only want a few apps from a full KDE package but the -meta ebuilds are just stupid, and I want to avoid them if I can. KDE is already way too long to compile, and those split ebuilds are only making it worse. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
