[kde-linux] 'Fetch Error' on exit

[Duncan]

Thomas Taylor posted on Tue, 07 Feb 2012 23:31:00 -0800 as excerpted:

> On Wed, 8 Feb 2012 02:56:41 +0000 (UTC)
> Duncan <1i5t5.duncan at cox.net> wrote:
> 
> <<<<< snip >>>>>
> 
>> FWIW, I got fed up with akonadi, however, and unmerged all of kdepim in
>> ordered to be able to unmerge it.  With it unmerged, I was able to set
>> USE=-semantic-desktop, etc, so I have all that turnakonadied off as
>> well.  You'd be AMAZED at how much faster kde runs now!  I know I was
>> --
>> it was like an MSWormOS user finding out how much either the malware or
>> the malware scanners had been slowing him down or like getting a free
>> half-gigahertz or another couple cores CPU upgrade!  I was /reasonably/
>> happy with kde4 before, but now I'm MUCH happier with it! =:^)
>> 
>> 
> <<<<< snip >>>>>
> 
> Hi Duncan:
> How does one unmerge akonadi?  I'll assume you don't mean just disabling
> the Nepomuk Search engine in configuration.  A brief outline of the
> procedure would be appreciated.
> 
> Thanks, Tom

[Note to other readers: this post is gentoo-package-management specific 
discussion so is unlikely to be of interest to non-gentoo kde users.]

First, how do you have kde installed?  By that, I mean what bits of it 
are in your world or world_sets files?  Do you simply have kde-meta (or 
the equivalent set) in world and let it pull in pretty much all of kde as 
dependencies, or do you install the category metas/sets (kdegames-meta 
kdegraphics-meta, etc) you want and let them pull in individual packages 
as dependencies, or do you install the the leaf packages you want 
(possibly by customizing a preexisting set or meta-package) and let them 
pull in the libs, etc, as dependencies?

Here, sets support (as found in portage-2.2.0-alphas) is critical to the 
way I manage things, using the third method, individual packages, managed 
here by modifying the sets found in the gentoo/kde overlay.  Every 4.x 
release (so 4.7, 4.8, etc), the sets change a bit, and I go thru and 
update my own customized sets to match, commenting out the libs (which 
are pulled in as needed) and any packages I don't specifically want (tho 
again, they'll sometimes be pulled in as dependencies anyway, if they're 
needed by a package I DO have marked as specifically wanted, that is, 
uncommented, in the set).

The important distinction, however, is that I'm managing individual 
packages, not the meta-packages (or unmodified sets) at either the 
category level or all-kde.  If you're choosing unmodified meta-packages/
sets instead of individual packages, the procedure you use will be 
different, especially if it's the global kde set or kde-meta package 
instead of the individual category sets/metapkgs.

If you have the unmodified kde-meta (or its parallel "kde" set) currently 
merged, at minimum, you'll need to merge the individual component 
metapackages/sets that you use, instead.  Take a look at the kde-meta 
ebuild or the kde set for a list, merge the ones you want so they're in 
your world or world_sets file, and unmerge the global kde set or kde-meta 
package.  (Just umerge the global, not its dependencies.  Then run emerge 
--depclean --pretend and see if you missed anything that you want added 
to world or world_sets and do so, before running it without the pretend.)

Once you have the category sets or metapackages installed and not the 
global kde set or kde-meta package, or if you have been only merging 
individual packages all along, it's more straightforward.

If you're running the category sets/metapackages, as I mentioned, pretty 
much anything kdepim will pull in akonadi.  Thus, you need to unmerge 
kdepim.  However, before you do that, do an emerge --depclean --pretend 
and take care of what comes up, either unmerging it or adding it to your 
world file or sets pulled in by world_sets.  Once you can do an

emerge --depclean --pretend without anything appearing on the list, go 
ahead and unmerge kdepim-meta, or remove the appropriate set from 
world_sets, or whatever.  Now run emerge --depclean --pretend again.  The 
new list is all the packages that were part of kdepim along with their 
dependencies.  kmail, kaddressbook, akonadi, knode, korganizer, and a few 
other packages are part of kdepim and should be listed to remove.  If you 
used anything on the list, be sure you have a replacement for it (or 
don't care enough about it to bother), before doing the removals.

Here's where you get interested if you had individual packages merged 
instead of the metapackages/sets, but it  applies if you had the kdepim 
metapackage/set installed too.  I assume by this point you've already 
switched off of kmail, knode, etc, and unmerged them.

Do an equery depends akonadi.  You may still see kdepim-common-libs on 
the list, being pulled in by something else, possibly due to a USE flag 
dependency which you'll have to adjust.  (You can do an equery depends 
kdepim-common-libs to see what's pulling it in, then check the abuilds 
themselves to see what flag pulls in that library.)

Once you've depcleaned all of kdepim, adjusting USE flags as necessary to 
be able to depclean/safely-unmerge kdepim-common-libs, etc, and have 
otherwise cleared everything from the equery depends akonadi list, 
depcleaning akonadi itself should be safe and possible.

Once akonadi is out of the way, if desired, you can then continue by 
trying to set USE=-semantic-desktop, then see what an emerge --ask --
newuse gives you.  You can't turn off USE=semantic-desktop until akonadi 
is unmerged, however, because it requires semantic-desktop.  There are 
probably a few other USE flags you can unset and packages you can then 
unmerge as well, virtuoso, redland, rasqual...  But you'll have to 
remerge kdelibs, dolphin, and other misc packages that were built with 
USE=semantic desktop in ordered to clear out the dependencies and be able 
to safely unmerge/depclean it all.  It actually took me several rounds, 
depcleaning/unmerging akonadi, setting USE=-semantic-desktop, doing some 
emerge --newuse remerges and I think a revdep-rebuild, unsetting another 
couple USE flags and doing a couple more --newuse rebuilds, depcleaning a 
couple more packages, doing another revdep-rebuild just to be sure... of 
course restarting kde a couple times since I had rebuild kdelibs, etc.


Once it's all cleared out, however, as I stated, I was actually rather 
surprised at how much faster kde ran!  I knew that was a lot of cruft I 
was cleaning out, but I didn't realize it would make THAT much 
difference.  I do hope it makes a similarly definitely noticeable 
(understatement) difference for you.  If you do remove all this, or just 
remove akonadi and keep semantic-desktop, please do report if it does 
make a noticeable difference for you.  If you say it doesn't make a 
noticeable difference I'll surely tone down my recommendation some, but 
I /was/ really surprised at the difference it made here, and based on 
that, expect that it'll make at least /some/ noticeable difference for 
you as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman