From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Re: KDE, metapackages, and monolithic packages
Date: Mon, 27 Feb 2006 17:13:48 -0700 [thread overview]
Message-ID: <pan.2006.02.28.00.13.47.915529@cox.net> (raw)
In-Reply-To: 44023455.3040906@gmail.com
Mike Myers posted <44023455.3040906@gmail.com>, excerpted below, on Sun,
26 Feb 2006 17:05:57 -0600:
> Do you know if there's a way or going to be a way to handle the split
> ebuilds so that reemerging or unemerging a split ebuild will reemerge or
> unemerge the corresponding packages? It seems like the ebuilds are only
> intended to make installing kde easier, which they do, but it doesn't
> make handle uninstalling or reinstalling a split ebuild very easy at
> all.
As others have said it's a technical/portage issue.
Unmerging a package always leaves dependencies behind. To clean those
up, emerge -NuD world (to ensure use dependencies are uptodate), emerge -p
depclean (to get a list of what it thinks is unneeded), fix anything on
that list you know to be needed (add it to world), then either unmerge
individually (as I do, even then, ensuring I haven't missed adding
something to world that I should have, verifying what each package does
and thinking about whether I actually do need it as I go) or if you
prefer, use the depclean without the -p, then, finally, do a
revdep-rebuild (first -p it, of course) to catch any dependencies that
still might have slipped thru and need rebuilt.
Upgrading is a bit more sensitive. However, with things like KDE
upgrades, I'll often use the --prune parameter on emerge, combined with -p
first of course. Then again, I unmerge manually as necessary. One other
method I've used is to do an equery list of kde packages, then grep it
for the version I want to unmerge, to get a list of old packages. So an
upgrade from 3.4 to 3.5 I'd grep for 3.4. Finally, when you've unmerged
most old KDE packages, take a look at the old /usr/kde/<ver> dir and see
what's left there, then do equery belongs <file> with what's left, to
figure out the packages they belong to. Anything left over that doesn't
belong to a package should be deletable, or if you prefer to be safe, move
it to a backup dir for a month or so first, so you can restore it if
necessary. Again, after unmerging stuff, a revdep-rebuild is recommended.
As others said, please move futher discussion to either user or desktop.
I don't look at user, but I'm a regular over in desktop, where KDE
questions are happily answered, as it's certainly part of desktop.
--
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2006-02-28 8:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-25 8:32 [gentoo-dev] KDE, metapackages, and monolithic packages Mike Myers
2006-02-25 9:06 ` Diego 'Flameeyes' Pettenò
2006-02-25 18:33 ` Mike Myers
2006-02-25 18:44 ` Sebastian Bergmann
2006-02-25 18:45 ` John Myers
2006-02-25 20:07 ` Mike Myers
2006-02-25 20:15 ` Matthijs van der Vleuten
2006-02-26 10:52 ` [gentoo-dev] " Duncan
2006-02-26 23:05 ` Mike Myers
2006-02-27 0:56 ` Richard Fish
2006-02-27 10:09 ` Paul de Vrieze
2006-02-28 0:13 ` Duncan [this message]
2006-02-25 9:06 ` [gentoo-dev] " Petteri Räty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2006.02.28.00.13.47.915529@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox