|Summary:||Optionally autoclean unwanted slots|
|Product:||Portage Development||Reporter:||Chris Torske <ct85711>|
|Component:||Enhancement/Feature Requests||Assignee:||Portage team <dev-portage>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Chris Torske 2006-02-02 18:49:44 UTC
Comment 1 Zac Medico 2006-02-11 10:13:46 UTC
What you really want it a better way to remove unneeded packages. Pretending that a slotted package is unslotted doesn't seem like a desirable approach. It seems better to give you an improved way to detect and unmerge unneeded slots (an improved version of `emerge --prune`).
Comment 2 Chris Torske 2006-02-11 16:32:31 UTC
I could careless of the exact implementation, as that is why I am allowing you guys think of how to do it. The main intention that I was going by; is there is some people which does need multiple copies of mysql and other slotted packages; while other people doesn't while not causing much of overhead (I think this won't cause much overhead). So I was going for flexability; giving the user as much of a choice as they like. Like I can understand some would like haveing multiple versions of gcc; I for one don't need more then 1 copy. As when I program in C/C++ I go for the current stable compilers; while I know others like to have the newest compiler (like gcc 4+) so they can port their code to that compiler too. The only problem I see on the improved prune that you are saying is; you can't be sure if someone needs multiple copies of 1 package or not. As you know more likly better then me there is some packages that just isn't in portage yet; specialy if it was just coded by you. So you will need some way to over-ride the defaults in the end, to provide the ability for thoose unknown packages (using the overlay tree for that is just like using a jackhammer to hammer in a simple nail).
Comment 3 Zac Medico 2006-10-06 18:17:32 UTC
This request seems to be within the domain of package sets. For example, one would be able to unmerge the kde-3.4 set after an upgrade to the kde-3.5 set.
Comment 4 Carsten Lohrke (RETIRED) 2006-10-07 04:31:47 UTC
(In reply to comment #3) > This request seems to be within the domain of package sets. For example, one > would be able to unmerge the kde-3.4 set after an upgrade to the kde-3.5 set. And you'd have to rebuild all packages depending on KDE 3.4. Same for compiler updates, etc.. There are even a couple of packages you cannot un-slot (without breaking your system). I think implementing this (at least in the current state, not tracking all dependencies/ABI breakages) is pretty pointless, as you have to care for the changes to be done manually anyways. I don't think we should support this. The argument "tedious kde meta packages" doesn't hold anyway, since all it needs is writing a simple script once and when proper sets are implemented, it'll be not more than emerge -C kde.
Comment 5 Zac Medico 2006-10-07 12:22:09 UTC
(In reply to comment #4) > when proper sets are implemented, it'll be not more than emerge -C kde. I think you and I are on the same page. I know that we can't really "unslot" slotted packages. ;)
Comment 6 Marius Mauch (RETIRED) 2008-03-02 15:56:56 UTC
I think we can consider this fixed with the current --depclean behavior.