| 1 |
Anthony Gorecki posted <200510290256.15093.agorecki@××××××××××.com>, |
| 2 |
excerpted below, on Sat, 29 Oct 2005 02:56:11 -0700: |
| 3 |
|
| 4 |
> On Saturday, October 29, 2005 02:48, Hamish Marson wrote: |
| 5 |
>> So what's gone wrong now? I even rmeoved kde & started again, and just |
| 6 |
>> seem to be back to square one again... |
| 7 |
> |
| 8 |
> You're attempting to use the monolithic and segregated KDE packages at the |
| 9 |
> same time. As far as I know, that isn't supported. |
| 10 |
> |
| 11 |
> If you want kmail, for example, just emerge the kmail package. You don't |
| 12 |
> need kdebase, kdepim, and so forth. |
| 13 |
|
| 14 |
Just what I was going to post, but I've some more details/exceptions to |
| 15 |
add. |
| 16 |
|
| 17 |
* Basically, I think you got confused between kde-meta and simple kde. |
| 18 |
See the last point below, but if some split packages are already merged, |
| 19 |
you problaby want kde-meta, not plain kde. |
| 20 |
|
| 21 |
* Even for the split packages, arts and kdelibs are monolithic, just as |
| 22 |
they'd be with the full monolithic builds. All the KDE builds depend on |
| 23 |
kdelibs and if USE=arts, arts. After that, one can merge individual |
| 24 |
packages as desired and additional dependencies will be pulled in as |
| 25 |
needed. (Here, with a dual Opteron and kde builds that don't parallelize |
| 26 |
that well, I'll often run three builds, each with -j3, at once. That |
| 27 |
won't work with kmail if you use USE=kdeenablefinal tho unless you have |
| 28 |
LOTS of memory, as with enablefinal active, I watched one particular |
| 29 |
compile thread climb to something like 780MB at one point (on the |
| 30 |
kde-3.5-betas, but kmail has been a compile time memory hog for several |
| 31 |
releases at least), and I'm not even sure that was the max it used, only |
| 32 |
the max I SAW it use! |
| 33 |
|
| 34 |
* I haven't actually tried it, but I /believe/ all you have to do is |
| 35 |
ensure you don't merge any of the split packages from the specific |
| 36 |
monolithic package they originate in, to avoid the blockage. kdebase, for |
| 37 |
one, since it's all basic stuff mostly needed to run the environment or |
| 38 |
konqueror or as a dependency for other packages anyway, could also |
| 39 |
probably be merged from monolithic. I believe the devs said that the |
| 40 |
monolithic packages each provide the packages they include, as well as |
| 41 |
blocking them, so there should be no dependency problems as long as you |
| 42 |
don't merge any split packages from a monolithic package you plan to merge. |
| 43 |
|
| 44 |
* If you just want everything without spending the time to pick and |
| 45 |
choose, emerge kde-meta, rather than kde, and it should merge just fine, |
| 46 |
without blocking on the individual split packages you apparently already |
| 47 |
have installed. |
| 48 |
|
| 49 |
IOW, kde-meta <> kde. The same files are ultimately merged, yes, but |
| 50 |
kde-meta does it by merging the individual split packages, while kde will |
| 51 |
attempt to merge the monolithic packages, and will fail with block errors |
| 52 |
if any of the split packages are already merged. Thus, once you have |
| 53 |
split packages merged, either use kde-meta, or unmerge all the split |
| 54 |
packages and merge kde before trying anything else. |
| 55 |
|
| 56 |
-- |
| 57 |
Duncan - List replies preferred. No HTML msgs. |
| 58 |
"Every nonfree program has a lord, a master -- |
| 59 |
and if you use the program, he is your master." Richard Stallman in |
| 60 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 61 |
|
| 62 |
|
| 63 |
-- |
| 64 |
gentoo-amd64@g.o mailing list |
Archives