Re: [kde-linux] 'Fetch Error' on exit
- Date: Wed, 8 Feb 2012 10:00:06 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] 'Fetch Error' on exit
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@xxxxxxx> 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
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.