| Summary: | Optionally autoclean unwanted slots | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Chris Torske <ct85711> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | anakin.skyw |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 144480 | ||
|
Description
Chris Torske
2006-02-02 18:49:44 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`). 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). 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. (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. (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. ;) I think we can consider this fixed with the current --depclean behavior. |
