I have been noticing more and more packages starting to be slotted. I would like it if there is a ability where we can tell portage to ignore the slotting of a specific package. The reason is because some of the packages, not everyone needs several different copies of the same package on their system; specialy for the people that is running ~arch. I do agree slotting is nice for some of the packages, but some users don't need 3+ verrsions of mysql, or 4 different versions of kde. As it is; portage will happily keep on adding more versions of the same package on the computer and allow them to run semi-idependently (of course with the exception of them relying on the same port/socket/file). So to allow the user/admin more flexability; to choose which packages they only need 1 version of; and not have to guess what version they currently have on the system and remove each of the other packages which can get very tedious specialy on sets like kde; which almost all their packages are slotted. Now to make it somewhat easier; instead of having it as a flag; have the feature check for a file like package.unslot; which will have the same syntax like the masking would. But will tell portage to treat the package as it wasn't slotted to begin with.
Not sure if you want the emerge info, as this is more of arch independent, but here it is anyways just in case.
Portage 2.1_pre4-r1 (default-linux/amd64/2006.0, gcc-3.4.5, glibc-2.3.6-r2, 2.6.15-gentoo-r2 x86_64)
System uname: 2.6.15-gentoo-r2 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.12.0_pre15
dev-lang/python: 2.3.5-r2, 2.4.2
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
CFLAGS="-O3 -pipe -march=k8"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O3 -pipe -march=k8"
FEATURES="autoconfig distlocks sandbox sfperms strict"
Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
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.