[gentoo-amd64] unmerging slotted group packages

[gentoo-amd64] unmerging slotted group packages

[Daiajo Tibdixious]

I discovered by accident that I have KDE 3.3, 3.4, & 3.5 all installed
at the same time.
I wanted to clean out 3.3 (at least) and tried emerge -aC
=kde-base/kde-3.3.0 which of course just did this pseudo package, not
the containing packages.
I also tried emerge --clean kde-base/kde but this says nothing to
remove, even though 3.4 & 3.5 are still present:
[D] kde-base/kde
     Available versions:  (3.5)  3.5.2 3.5.5
     Installed:           3.4.3(3.4)(17:19:35 01/18/06)(-accessibility)
                          3.5.5(3.5)(02:50:53 12/10/06)(-accessibility)
     Homepage:            http://www.kde.org/
     Description:         KDE - merge this to pull in all
non-developer kde-base/* packages

I got rid of 3.3 by doing eix -I kde & removing each sub-package
manually, I just think I must be missing an easier way.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] unmerging slotted group packages

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

On Sun, 28 Jan 2007 16:17:37 +1100, Daiajo Tibdixious wrote:

> I discovered by accident that I have KDE 3.3, 3.4, & 3.5 all installed
> at the same time.
> I wanted to clean out 3.3 (at least) and tried emerge -aC
> =kde-base/kde-3.3.0 which of course just did this pseudo package, not
> the containing packages.

> I got rid of 3.3 by doing eix -I kde & removing each sub-package
> manually, I just think I must be missing an easier way.

eix -A kde-base -Icn | awk '/kde-base/ {print $2}' | xargs emerge --Prune --pretend

Then remove --pretend when you are satisfied with what it wants to remove.


-- 
Neil Bothwick

Employ teenagers - while they know everything.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] unmerging slotted group packages

[Peter Humphrey]

On Sunday 28 Jan 2007, Daiajo Tibdixious wrote:

> I got rid of 3.3 by doing eix -I kde & removing each sub-package
> manually, I just think I must be missing an easier way.

Looks like you could just have waited for Paludis to arrive (see the latest 
GWN).

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] unmerging slotted group packages

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Humphrey wrote:
> On Sunday 28 Jan 2007, Daiajo Tibdixious wrote:
> 
>> I got rid of 3.3 by doing eix -I kde & removing each sub-package
>> manually, I just think I must be missing an easier way.
> 
> Looks like you could just have waited for Paludis to arrive (see the latest 
> GWN).
> 

Is anybody actually using this on amd64?  It looks interesting but
they've had about 6 releases in the last 30 days.  I'm also not sure how
much of an official blessing it has.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFvI8VG4/rWKZmVWkRAgZ4AKCewBXRTV8Re0Pf7L8ZTPmCF30hXACglsRc
J81jbE2dHYaxLRU2fitKgjI=
=VSuJ
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

Re: [gentoo-amd64] unmerging slotted group packages

[Peter Humphrey]

On Sunday 28 Jan 2007, Richard Freeman wrote:

> Is anybody actually using [paludis] on amd64?  It looks interesting but
> they've had about 6 releases in the last 30 days.  I'm also not sure how
> much of an official blessing it has.

I thought I'd give it a spin, but then I thought better of it when I saw the 
extent the developers have gone to to deter us from experimenting yet, so 
I've ditched it for now.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] unmerging slotted group packages

[Daiajo Tibdixious]

Both suggestions sound good. I did read about Paludis but still sounds
like vapourware. :(
--prune sounded scary in the man page for emerge.
I also need to learn awk, heard about it, never used it, looks cool,
it produces precisely the action I wanted, thanks.

On 1/28/07, Peter Humphrey <prh@gotadsl.co.uk> wrote:
> On Sunday 28 Jan 2007, Daiajo Tibdixious wrote:
>
> > I got rid of 3.3 by doing eix -I kde & removing each sub-package
> > manually, I just think I must be missing an easier way.
>
> Looks like you could just have waited for Paludis to arrive (see the latest
> GWN).
>
> --
> Rgds
> Peter
> --
> gentoo-amd64@gentoo.org mailing list
>
>
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: unmerging slotted group packages

[Duncan]

"Daiajo Tibdixious" <daiajo@gmail.com> posted
a4a9bfcb0701272117g58fdd9beof34ecba152619063@mail.gmail.com, excerpted
below, on  Sun, 28 Jan 2007 16:17:37 +1100:

> I discovered by accident that I have KDE 3.3, 3.4, & 3.5 all installed
> at the same time.
> I wanted to clean out 3.3 (at least) and tried emerge -aC
> =kde-base/kde-3.3.0 which of course just did this pseudo package, not
> the containing packages.
> I also tried emerge --clean kde-base/kde but this says nothing to
> remove, even though 3.4 & 3.5 are still present:
> [D] kde-base/kde
>      Available versions:  (3.5)  3.5.2 3.5.5
>      Installed:           3.4.3(3.4)(17:19:35 01/18/06)(-accessibility)
>                           3.5.5(3.5)(02:50:53 12/10/06)(-accessibility)
>      Homepage:            http://www.kde.org/
>      Description:         KDE - merge this to pull in all
> non-developer kde-base/* packages
> 
> I got rid of 3.3 by doing eix -I kde & removing each sub-package
> manually, I just think I must be missing an easier way.

Two easier ways to do it, but with both, use --pretend first and ensure
it's not going to remove something you know you need.  Both of these
depend on your world file being accurate, so proceed with caution if you
know it's not.  Each separate section is bullet-pointed with **, below,
hopefully making it easy to follow.


** First, some general maintenance.  You may have a bit of cleaning up to
do here if you've not done it in awhile.

There's a step that's normally recommended before the following, only at
this point it'd likely cause a bunch of extra work due to stuff you will
be removing anyway, so I'd say skip it this time.  However, I'll note it
at the bottom under pre-maintenance, and I'd suggest reading thru this
entire message so you understand how it all works, before you start.

OK, do an emerge --pretend --depclean, and see what's listed.  It
should list everything that's not either in your world file or a
dependency of something in your world file.  That's what portage thinks
you don't need.  If you think you need something on that list, do an
emerge --noreplace <package> so portage will add an appropriate entry to
your world file for it.   (If it's a dependency, aka a branch package that
something else depends on, as usual, add the "leaf" packages that depend
on it, thus keeping only "leaves" in your world file, so when all of them
are removed, portage knows it can remove the dependency as well.)

Once you have all the packages in your world file you know you need, so
--depclean --pretend is only listing stuff that should be safe to remove
(it won't be listing the KDE slots stuff at this time, most likely), go
ahead and do the emerge --depclean without the pretend.

That should leave you with all the "extra" packages removed.  Generally,
these will be old dependencies for "leaf" packages, old/dead branches with
no current leaves.  Up to this point you should do relatively frequently,
just keeping the old cruft on your system to a minimum, as part of regular
maintenance.

There is another part to this that you should normally do whenever you are
doing it for system maintenance.  However, we'll skip that here since
it could mean a bunch of extra work for stuff you are going to remove
anyway.  Thus, I'll list it at the bottom, under completing the system
maintenance, after the old-KDE removal stuff.


** OK, now here's method 1, specifically unmerging the old kde slots:

Specifically emerge --unmerge =kde-<old-ver>.  This will unmerge the
meta-package that's the leaf for all the other KDE packages (branches
supporting that leaf) of that version.

** And here's method 2, using --prune:

Emerge --prune will try to unmerge all but the most recently merged version
of the packages in question. That's likely what you want for things like
KDE, but it's definitely NOT what you want for things like autoconf and
automake, for instance, since many packages depend on older versions and
won't work with newer ones.  Thus, ALWAYS use --pretend the first time you
use --prune, just to be SURE it's going to remove what you expect it to,
and nothing else, and NEVER do an emerge --prune world or system (except
if you are curious, you can try it with --pretend, just to see what it
would do if you were stupid and tried --prune world without the pretend).

So... emerge --pretend --prune kde-base/kde, and see what it lists.  If
it looks sensible and it should, run it again without the pretend.

** Finishing up the unmerge:

OK, either way you did it, you should now be clear of the old kde
meta-packages, but you'll still have the actual packages merged.
However, once the metapackage is unmerged, you can again run emerge
--depclean --pretend, and portage should list all the dependencies of the
slot leaf you just removed as stuff it'd now remove.  If it looks correct,
go ahead and do it again, this time without the --pretend. Again, if
there's something listed that you know shouldn't be, do an emerge
--noreplace <package> for it so portage adds it to the world file, then
when everything looks good, go ahead and remove the --pretend.


** Completing the system maintenance, revdep-rebuild:

OK, now you should have all the old cruft removed, but we aren't quite
finished yet.  There's a possibility that some of the remaining packages
are now broken, because they had seen and compiled against some of that
old cruft, even tho they /should/ have compiled against newer stuff. 
Broken dependencies can also happen when you changed USE flags and didn't
recompile everything that used those flags with the new flags.  --depclean
doesn't understand these cases, and so sometimes removes stuff that's
still needed, but there's a tool designed to fix it: revdep-rebuild, which
is part of gentoolkit.

So, if you don't have gentoolkit merged, emerge it.  Then, run
revdep-rebuild --pretend (remember, unlike --depclean, revdep-rebuild is
it's own command, not part of emerge). Depending on the speed of your disk
and amount of memory, revdep-rebuild will take a half an hour or so to
scan all the executables and libraries on your system and ensure they have
all their library dependencies met. If they don't, it'll figure out what
you have to remerge to get things working again, and either do it, or with
pretend, give you a list.  If you've not been keeping up with system
maintenance, especially if you just --depcleaned a bunch of stuff as we
just did, and/or if you don't regularly do emerge --newuse world after
changing your USE flags, you'll likely have a bit of a list of stuff that
needs rebuilt, thus the --pretend the first time, so you get a bit of
warning at how long it might take.

Once you know what revdep-rebuild thinks you need to remerge, you can run
it again without the --pretend, and it'll do it.  (It won't take all that
time figuring stuff out again, as if there's actually anything it needs
to remerge, it saves the work files from the --pretend, so it can get
right to work the second time.)

Once you have everything rebuilt, if you like or I'd recommend it if
you had a lot to rebuild, you can run revdep-rebuild --pretend once more,
just to be sure.  Once it says you are clean, you'll have a nicely
sparkling clean system, freshly de-crufted and with all dependencies
verified by revdep-rebuild.  =8^)


** Pre-maintenance, emerge --newuse and revdep-rebuild:

As I explained near the top, emerge --depclean is an important part of
what should be routine system maintenance, just to keep your system free
of cruft.  However, when done routinely, there's a couple things you can
do before the --depclean to keep things from breaking with the removal
of that cruft and therefore needing rebuilt with revdep-rebuild.  I
suggested skipping them this time only because with all that old stuff on
your system, you'd have likely been doing a lot of extra merging for stuff
that you were just getting ready to clean out.  However, if you do it
routinely, say every three or six months, after any big removals such
as old KDE slots, and after changing your use flags, there won't be that
much stuff out of date anyway, so doing this pre-maintenance is a good
idea as it'll keep stuff from breaking with the --depclean.

For routine maintenance, then, your first steps should be the following:

emerge --newuse world (first with --pretend, or with --ask, of course). 
This makes sure all packages are remerged that have had their USE flags
changed. Since USE flags often determine dependencies, changing USE flags
often means changing dependencies, and remerging any packages with changed
flags then updates the dependencies so they don't break when --depclean
removes stuff based on current USE flags.

revdep-rebuild (again, first with --pretend, or with --ask).  Do this
before your emerge --depclean, after emerge --newuse, and in theory,
nothing should be broken after your emerge --depclean.


** Summary of routine system maintenance, step by step:

Here, in short form and for further reference, are the steps that should
be done routinely, say every 3-6 months, and after USE flag changes or
after major upgrades (stuff like KDE, GNOME, XORG, GCC, etc).

1) emerge --newuse world
2) revdep-rebuild
3) emerge --pretend --depclean
4) emerge --noreplace <package> as necessary
5) emerge --depclean
6) unmerge old slots or major packages if desired
7) repeat steps 3-6 as necessary
8) revdep-rebuild
9) verify with another revdep-rebuild if desired

Nice clean system! =8^)

If done in this order, there shouldn't be much if anything to
revdep-rebuild the second time, in step 8.


** Notes:

- Again, while skipping step 1 and 2 if you haven't been keeping up with
the routine maintenance steps above does mean a bigger risk of stuff
broken, I'd still recommend it in your case right now, simply because it's
likely if you tried doing the above in order, you'd have a lot of packages
to rebuild in steps 1 and 2 only to support stuff you are removing in step
6.  However, if you'd prefer to do the perhaps significant extra work and
avoid as much breakage as possible, go ahead and do it this way this time,
as well.

- revdep-rebuild scans elf files, that is, native elf format binary
executables and shared object libraries.  While that gets most of the big
and critical stuff, revdep-rebuild doesn't understand perl/python/ruby/etc
dependencies, and thus won't rebuild them.  For those types of things,
there are other tools, such as python-updater, for python.

- There's another specialized tool for dealing with all those
*.la libtool files, helping them find libstdc++, as provided by the gcc
package. Every time you unmerge old versions of gcc or when you get
libstdc++ errors trying to merge something, you should run
fix_libtool_files.sh <old/bad-gcc-ver>.  Thus, if you just unmerged or
it's complaining that it can't find the libstdc++ for gcc-3.4.6, for
instance, run fix_libtool_files.sh gcc-3.4.6, and it will scan all the
*.la files it can find and ensure all the entries listing that old
version also list your current gcc version, as pointed at by gcc-config. 
Just another tool to know about, as it sure comes in handy sometimes. =8^)

- I recommend that folks use FEATURES=buildpkg.  That portage feature
causes it to build and archive a binary version of every package it
merges, by default to $PORTDIR/packages.  You can then use emerge
--package (-k) or --packageonly (-K) if for some reason you need to
remerge an old version of something.  This comes in handy in a number of
cases, including if you used --depclean and unmerge something that you
figure out later you needed, but what wasn't in your world file or listed
as a dependency of anything in the world file, for whatever reason. 
Having a couple old versions around in binary package form is also handy
if something stops working right after an upgrade.  Having a binary
package of gcc around is nice as well, in case gcc breaks, and there are
even tricks that allow you to rescue a broken portage or python if you
have a binary package, when you'd otherwise be in pretty bad shape,
because portage is broken and won't let you emerge a new copy of it! 
Typically, packages for an entire system take up about a gig, so plan on
two gigs or so, just to have a bit of extra room.  eclean, now a part of
portage, can be used to manage both your packages dir and distdir, 
pruning old source and package files for ebuilds no longer in the tree.

- If you have emerged a lot of library files and other dependencies
without using --oneshot, so they ended up in your world file, --depclean
won't list or unmerge them when they are no longer needed, because they 
are in your world file.  This is the opposite of the problem above, in
that with the above problem, stuff you need isn't in the world file so
will be removed by --depclean, while here, stuff you no longer need
because it was a dependency of something you are no longer running is
listed in the world file, and thus won't be removed.  There's a tool to
fix this too. =8^)  If you know you have this problem, or just want to see
if you might, try emerging udept, which contains dep.  You can then run
dep --pretend --pruneworld, and get a list of entries in your world file
that it thinks are depends, and thus removable, since something else in
the file depends on them already.  There are a bunch of other things it
can do as well.  It includes its own --depclean implementation, for
instance.  However, while it's often faster than portage, it's also not
always as accurate.  Therefore, as usual, --pretend or --ask can be very
helpful, and you'll want to treat its results rather more skeptically than
you might portage's own.  With --pruneworld, for instance, it wanted to
remove a couple things from world that I found out later I needed there.
Similarly I tried running its depclean, and it wanted to remove QUITE A
FEW packages that were needed, and that portage's depclean knew were 
needed.  So it's a tool that helps, and since it's faster, I'll use it for
some things, but for things like --depclean, I wouldn't trust it at all,
as it DOES get things wrong sometimes, where portage's emerge --depclean
gets it right.

I'm sure that's more information than you had thought you were asking
for, but it's all quite usable here, and hopefully you'll find it equally
so there. =8^)

-- 
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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: unmerging slotted group packages

[Steve Herber]

Duncan:  Yet another great document about keeping a Gentoo system up to 
date.  I looked at the Gentoo Wiki site to see if they had anything
similar and the closest was the HOWTO Maintain Gentoo-Best_Practices
article:

http://gentoo-wiki.com/HOWTO_Maintain_Gentoo_-_%22Best_Practices%22

It would be nice if some of your material could be added to it because
your comments are good help for all Gentoo people..

Thank you,

Steve Herber	herber@thing.com		work: 206-221-7262
Security Engineer, UW Medicine, IT Services	home: 425-454-2399

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: unmerging slotted group packages

[Daiajo Tibdixious]

Replying to Duncan,
Thanks, very informative. I've been doing everything except for
--depclean, as that has never worked. Now I see that it is because of
kde-3.4 which was built with samba (which I have now removed) and a
version of qt that is no longer there.

I used Neil's awk command to remove kde-3.4 and now --depclean works.

I have now more than 130 orphaned packages. After removing a lot of
gnome related items (I've never run gnome on this system) and a lot of
other things I recognised, I still have more than 130 orphaned
packages, even tho the number of installed packages went from 608 to
563!
This could take a while, especially as revdep-rebuild is complaining a
lot about stuff I've removed.

BTW
FEATURES="buildpkg parallel-fetch fixpackages"
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: unmerging slotted group packages

[Duncan]

"Daiajo Tibdixious" <daiajo@gmail.com> posted
a4a9bfcb0701281548i25d6e8ev80659330e67abe6f@mail.gmail.com, excerpted
below, on  Mon, 29 Jan 2007 10:48:28 +1100:

> I used Neil's awk command to remove kde-3.4 and now --depclean works.
> 
> I have now more than 130 orphaned packages. After removing a lot of
> gnome related items (I've never run gnome on this system) and a lot of
> other things I recognised, I still have more than 130 orphaned
> packages, even tho the number of installed packages went from 608 to
> 563!
> This could take a while, especially as revdep-rebuild is complaining a
> lot about stuff I've removed.

Yeah, if you let yourself get behind on general system maintenance, it
/will/ come back to bite you, either if you're unlucky when stuff stops
compiling correctly because of all the cruft laying around or worse yet
when something that hasn't been updated has a security vuln that gets
exploited =8^(, or if you are lucky, you get to the maintenance first, but
it's just a huge hassle because there's so much to sort thru.

> BTW
> FEATURES="buildpkg parallel-fetch fixpackages"

=8^)

-- 
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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: unmerging slotted group packages

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On Mon, 29 Jan 2007 10:48:28 +1100, Daiajo Tibdixious wrote:

> I have now more than 130 orphaned packages. After removing a lot of
> gnome related items (I've never run gnome on this system) and a lot of
> other things I recognised, I still have more than 130 orphaned
> packages, even tho the number of installed packages went from 608 to
> 563!
> This could take a while, especially as revdep-rebuild is complaining a
> lot about stuff I've removed.

This is to be expected if you remove only some of the packages listed by
depclean, as other packages in the list may depend on them. This is
because revdep-rebuild works with installed files not the package list.

Wait until you have removed everything in the list before running
revdep-rebuild and then emerge -uavDN world.


-- 
Neil Bothwick

Maybe... How much are you bribing me this time?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: unmerging slotted group packages

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On Sunday 28 January 2007 13:16:37 Duncan wrote:
> OK, either way you did it, you should now be clear of the old kde
> meta-packages, but you'll still have the actual packages merged.
> However, once the metapackage is unmerged, you can again run emerge
> --depclean --pretend, and portage should list all the dependencies of the
> slot leaf you just removed as stuff it'd now remove.

I didn't really have the patience to read all the way through your post but 
this part does appear to be incorrect.

The world file can only contain package names (neither slots nor versions) so 
removing kde-3.4 while keeping kde-3.5 is not going to change what's in the 
world file. If something in the world file depends on kdelibs-3.5 then 
`emerge --depclean` will not remove kdelibs-3.4 or any other old slots that 
really aren't needed anymore.

Only --prune or --unmerge will do that and both of those currently have the 
downside that they don't check whether it's still needed (as in the case of 
autoconf, automake etc.). Implementing a safer --prune reusing some of the 
code from --depclean (which was improved a lot in portage-2.1.1) has been 
discussed in the past but it isn't done yet.

Fortunately we do know that for any package in the kde categories pruning old 
slots is indeed safe.

-- 
Bo Andresen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: unmerging slotted group packages

[Duncan]

Bo Ørsted Andresen <bo.andresen@zlin.dk> posted
200701291131.54208.bo.andresen@zlin.dk, excerpted below, on  Mon, 29 Jan
2007 11:31:46 +0100:

> I didn't really have the patience to read all the way through your post but 
> this part does appear to be incorrect.
> 
> The world file can only contain package names (neither slots nor versions) so 
> removing kde-3.4 while keeping kde-3.5 is not going to change what's in the 
> world file. If something in the world file depends on kdelibs-3.5 then 
> `emerge --depclean` will not remove kdelibs-3.4 or any other old slots that 
> really aren't needed anymore.
> 
> Only --prune or --unmerge will do that and both of those currently have the 
> downside that they don't check whether it's still needed (as in the case of 
> autoconf, automake etc.). Implementing a safer --prune reusing some of the 
> code from --depclean (which was improved a lot in portage-2.1.1) has been 
> discussed in the past but it isn't done yet.

Thanks for the correction.  While I knew that world doesn't contain slots
or versions, I thought (and believe it works that way in ~portage, but it
may not have reached stable yet, and I could be wrong) that unmerging the
metapackage would then release the dependency on the other stuff in that
slot.  For KDE monolithics, for instance, I believe(d) that while
old kdelibs won't be unmerged immediately as it isdepended on by
kdebase which is depended on by (among others) kdegraphics, without the
old kde-3.4.x, kdegraphics-3.4.x would be trimmed by --depclean, and once
all the other kdewhatever-3.4.x packages had been trimmed, then
kdebase-3.4.x could be trimmed, and then kdelibs-3.4.x.

However, I'm using the split packages, not the monolithics, and don't have
kde-meta merged as I don't need all the split packages either.  That makes
it harder to test.  In addition, I unmerge old versions pretty quickly
once I've upgraded and found no critical non-working stuff (like say
konqueror or kmail, or anything having to do with the ability to run a KDE
desktop itself), keeping up with that system maintenance, so I've never
gotten to the point of having that much cruft to unmerge at once.  Thus,
that part wasn't tested, and you (naturally) had to call me on it. =8^) 
Still, genuinely, thanks, as if I'm not called on such things, I get lax,
and it's those I'm trying to help that get hurt, so I'd much rather get
called on my errors than not!

-- 
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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: unmerging slotted group packages

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Monday 29 January 2007 13:03:28 Duncan wrote:
> While I knew that world doesn't contain slots
> or versions, I thought (and believe it works that way in ~portage, but it
> may not have reached stable yet, and I could be wrong) that unmerging the
> metapackage would then release the dependency on the other stuff in that
> slot.  For KDE monolithics, for instance, I believe(d) that while
> old kdelibs won't be unmerged immediately as it isdepended on by
> kdebase which is depended on by (among others) kdegraphics, without the
> old kde-3.4.x, kdegraphics-3.4.x would be trimmed by --depclean, and once
> all the other kdewhatever-3.4.x packages had been trimmed, then
> kdebase-3.4.x could be trimmed, and then kdelibs-3.4.x

Nope. And it's not going to change anytime soon. A safer --prune, however, 
does have a good chance of going into portage 2.1.3 (to fix bug #151653).

> However, I'm using the split packages, not the monolithics, and don't have
> kde-meta merged as I don't need all the split packages either.

Doesn't really make a difference. The most basic deps (arts and kdelibs) don't 
differ at all. The problem with using kde as a test case is that kde-3.4 left 
the tree 4 months ago... ;)

-- 
Bo Andresen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]