Tonight I asked remi if I could clean up some old gtkhtml-3 slots and here is the result of a first check: $ ~/Projets/gentoo/slot-checker.py gnome-extra/gtkhtml | sort | uniq app-text/gnomesword-2.1.7 matches 4 slots (3.6, 3.2, 3.14, 3.8) with dep =gnome-extra/gtkhtml-3* dev-php5/php-gtk-2.0.0 matches 2 slots (3.14, 3.8) with dep >=gnome-extra/gtkhtml-3.10.0 dev-php5/php-gtk-2.0.1 matches 2 slots (3.14, 3.8) with dep >=gnome-extra/gtkhtml-3.10.0 mail-client/balsa-2.3.22 matches 5 slots (3.6, 3.2, 2, 3.14, 3.8) with dep gnome-extra/gtkhtml media-sound/solfege-3.10.3 matches 5 slots (3.6, 3.2, 2, 3.14, 3.8) with dep >=gnome-extra/gtkhtml-2 media-sound/solfege-3.10.4 matches 5 slots (3.6, 3.2, 2, 3.14, 3.8) with dep >=gnome-extra/gtkhtml-2 media-sound/solfege-3.8.2 matches 5 slots (3.6, 3.2, 2, 3.14, 3.8) with dep >=gnome-extra/gtkhtml-2 This bug is intended to inform you that it is probably not right for preserving consistent state of linking binaries upon a random gtkhtml slot removal to allow your ebuilds to select any slots. I intend to get through the list of ebuild listed here to make them use the most recent slot unless there is any objection or you beat me to it.
I just fixed packages in the list, thanks guys.
Sorry to burst your bubble but ... $ ~remi/Projets/gentoo/slot-checker.py gnome-extra/gtkhtml | sort | uniq Package ebuild src: dev-dotnet/gtkhtml-sharp-1.0.10 matches 2 slots (3.2, 3.14) with dep =gnome-extra/gtkhtml-3.2* Package ebuild src: dev-dotnet/gtkhtml-sharp-2.16.0 matches 2 slots (3.2, 3.14) with dep =gnome-extra/gtkhtml-3.2* Package ebuild src: dev-dotnet/gtkhtml-sharp-2.8.2 matches 2 slots (3.2, 3.14) with dep =gnome-extra/gtkhtml-3.2* After checking with portage gurus, gtkhtml-sharp should not be using "3.2*" since this atom does indeed match both "3.2.5" and "3.24.2". This package is a prime candidate for slotted deps. Have fun :D
fixed gtkhtml-sharp by using slotted deps, approved by loki_val.
