On Wed, Feb 12, 2014 at 2:46 PM, Chris Reffett <creff...@gentoo.org> wrote: > On 2/12/2014 3:09 AM, Michał Górny wrote: >> Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett >> <creff...@gentoo.org> napisał(a): >> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote: >>>>> Unfortunately, the concurrent nature of gtk2/gtk3 has >>>>> resulted in packages that may support either or both the >>>>> toolkits. To handle this, a few developers have introduced >>>>> the "gtk3" useflag, that prefers gtk3 over gtk2 when both >>>>> toolkit versions are supported. At this point, the Gnome >>>>> team highly recommends prefering gtk3 if possible, skipping >>>>> the useflag altogether. [1] >>>> >>>> Wrong, as is written in policy whether to prefer gtk2 or 3 is >>>> up to the maintainer of the package. We point people to the >>>> fact that upstream says gtk2 is a dead end and support will >>>> stop (if not in fact already stopped) in the near future. >>>> >>>> We also recommend to have maintainers support slots for their >>>> libs where possible considering man-power and to only choose >>>> one toolkit for applications considering where upstream >>>> development is going and maturity of the port, and again, this >>>> is up to package maintainers. >>> This doesn't make sense to me at all. I can't see why slotted >>> libraries can't just use USE flags to specify what toolkit >>> they're built against, just like any other package in the tree >>> (so, for example, a package that needs webkit-gtk built against >>> gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). >>> I'm well aware that there could be limitations I'm unaware of >>> (maybe the package only can build one at a time?), but this is >>> how it looks to me. By switching to versioned gtk flags, this >>> kills two birds with one stone: it makes it obvious to the end >>> user which version they're trying to build their package >>> against, and it gets rid of the need for (ab)using revision >>> numbers to implement slots like that. >> >> Except when you end up rebuilding the huge thing twice. Or trying >> to live with binpackages -- the thing that most Gentoo developers >> don't care about at all. They just love their precious USE flags >> so much they'd shove them everywhere for the sake of it. >> > > You'll have to build it twice anyway, this just splits it into two > separate packages, and I suspect that the times where you will have to > rebuild are when a package needs webkit-gtk to support another toolkit > (which should happen only once), and when you upgrade (in which case > you would be updating them separately anyway).
After talking to Chris on IRC, I think we've made progress. I claim that there's a fundamental distinction between USE flags controlling how the binaries are built and controlling *which* binaries are built. I think that the use of SLOTs here is perfectly reasonable, since webkit-gtk installs different libraries (not just the same library with different build options) in the two slots. There's apparently some disdain for using the -r200/-r300 versioning to control the slots, but I think if we want to clean that up we should look at modifying PMS to allow something cleaner.
