I recently emerged links-2.0_rc4-r1 [after dealing with some back-and-forth with gpm, etc.] and noticed that it installed just fine. However, when I did a qpkg -l links, I was presented with two different versions: the previous version and the current one. This would be fine, if the two versions didn't overwrite all of the same executables. After a bit of investigation, I discovered that the new ebuild has SLOT="0" and the old one doesn't. I started digging through qpkg --installed, and I found a number of different packages that have this problem. The output of qpkg --installed --dups follows: -- dev-libs/glib dev-libs/openssl gnome-extra/gnome-pilot media-libs/freetype media-libs/libdvdcss media-libs/libdvdread sys-apps/baselayout sys-apps/shadow sys-apps/util-linux sys-libs/db -- While some of these (freetype, glib) are intentional, others (util-linux, libdvdread, shadow) are definitely not; by doing a qpkg -l on them, you can see that they write all of the same binaries. This is definitely confusing for the end-user, and makes for a somewhat mangled portage database. After looking at the suspect ebuilds, they all had a new SLOT="0" line in them, which seemed to cause the duplication.
Daniel, I was under the impression that if no SLOT is specified, portage assumes SLOT="0" ?
Seemant: No, that is not the case. With no slot, Portage assumes SLOT="" (unslotted).
Then the ebuilds that have had 'SLOT="0"' added to them need to have that removed, or some other solution needs to be done. Else we're going to have duplicate versions of all of these programs in our ebuild databases.
Apps should have SLOT="0"
Closing this out. We've had enough discussions on this one, both on IRC and on the mailing lists, to know that the current SLOT-based behaviour is what we want.