ghex needs to be slotted to allow gtk2-based packages that use libgtkhex and gtk3-based packages that use libgtkhex-3 to be installed at the same time. I suggest doing it they way it's done in the overlay: http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=tree;f=app-editors/ghex;hb=refs/heads/gnome-next slot 3 installs the libgtkhex-3 library and the ghex executable. slot 2 installs the libgtkhex library and pdepends on slot 3. PS. Pacho, please, before bumping gnome3 and 3.2 packages, take a look at how they are handled in the overlay (incl. the gnome-next branch).
Ups, thanks for reporting and the heads up (I was too fast bumping as was waiting for a long time to get a ghex version without requiring old libgnomeprint) Regarding slotting, I have seen only nemiver would benefit for it and, if we bump to "current version" (as pointed in http://projects.gnome.org/nemiver/), it would also use ghex-3. Does it deserve the effort then to slot them and, later, need to lastrite old slot?
(In reply to comment #1) > Ups, thanks for reporting and the heads up (I was too fast bumping as was > waiting for a long time to get a ghex version without requiring old > libgnomeprint) > > Regarding slotting, I have seen only nemiver would benefit for it and, if we > bump to "current version" (as pointed in http://projects.gnome.org/nemiver/), > it would also use ghex-3. Does it deserve the effort then to slot them and, > later, need to lastrite old slot? Also taking care ghex-2 is dead (regarding upstream no longer maintaining it) and, then, any new package addition should use ghex-3 instead
(In reply to comment #2) > Also taking care ghex-2 is dead (regarding upstream no longer maintaining it) > and, then, any new package addition should use ghex-3 instead Anything that uses gtk2 cannot use libgtkhex-3. > Regarding slotting, I have seen only nemiver would benefit for it and, if we > bump to "current version" (as pointed in http://projects.gnome.org/nemiver/), > it would also use ghex-3. Does it deserve the effort then to slot them and, > later, need to lastrite old slot? IMHO, if a *library* has both gtk2 and gtk3 versions, and it's possible to support both gtk2 and gtk3 without too much pain, then our packages for that library should support both gtk2 and gtk3 (by slotting, USE flags, or whatever other mechanism) at least for the next year or two. In the case of ghex, libgtkhex and libgtkhex-3 are clearly designed to be installable in parallel (this parallel installability is even mentioned as a feature in the NEWS file), so the cost of slotting to us is minimal.
The problem is that I would prefer to try to drop old ghex-2.24 as soon as possible as it contains some bugs already fixed in newer versions and also depends on old packages that should be dropped if possible. Then, as only nemiver version is needing it (and it can be solved simply bumping to its current version), I think we shouldn't try to keep this old version more than necessary. Looking at ebuilds in overlay, looks like ghex-2.24.0-r200 would simply install gtkhex-2 lib... but none should need it in the near future (I really doubt any new software will be added to the tree relying on dead gtkhex-2 lib)
In a discussion on IRC, it appeared that nobody wanted to support a slotted ghex. So I am bowing to the inevitable. The nemiver-0.8.1 ebuild needs to be modified to depend on <app-editors/ghex-2.90, and then this bug can be closed.
OK, sorry for not appearing on IRC more frequently but I don't have much time these days :( Remi, I can bump and adjust RDEPEND for old nemiver if you want (or even bump and remove old as it's in testing ;-))
All should be ok now
