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
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:
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
After looking at the suspect ebuilds, they all had a new
line in them, which seemed to cause the duplication.
Daniel, I was under the impression that if no SLOT is specified, portage assumes
Seemant: No, that is not the case. With no slot, Portage assumes SLOT=""
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.