-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote:
> Thanks for attaching link to team's policy which tries to lift any
> kind of ambiguities people may have for what concerns gnome team's
> packages, I hope it proved useful in your discussions.
>
>
> Le mercredi 12 février 2014 à 00:39 +0200, Alex Alexander a écrit
> :
>> Hello fellow developers,
>>
>> In the first meeting of the new QA team, we discussed the state
>> of the gtk{,2,3} USE flags in the main tree. [0]
>>
>> In its current state, USE="gtk" means gtk2. The Gnome team is
>> trying to change this into "the most recent gtk version" (it is a
>> work in progress).
>
> Wrong, gtk USE flag means "enable gtk support", whether this is gtk
> 1, 2 or 3 depends on what the package (presumably library) supports
> and whether is can be slotted or not and whether current gentoo
> maintainer decides what can be reasonably supported.
>
>> 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.
>
>> Some developers choose to follow the Gnome team's highlights,
>> while others choose to go their own way. The QA team would like
>> to establish a guideline that solves this problem in the best way
>> possible.
>>
>> During our discussion, it was pointed out that keeping a generic
>> USE="gtk" is sub-optimal. The non-straightforward nature of new
>> toolkit versions makes transitioning from one to the other a
>> slow, tedius process and we think that a non-versioned USE flag
>> makes things even worse.
>>
>> A few of our members recommended a move away from the unversioned
>> USE="gtk" to versioned-only USE flags. Qt managed to do this
>> quite successfully when they transitioned from the unversioned
>> USE="qt" (that actually meant qt3) to USE="qt4". The benefits can
>> be seen now that qt5 is around the corner. USE="qt5" is
>> straightforward, does not mess with qt4 packages and was
>> introduced to the tree without messing with current packages too
>> much - other than adding a new use flag where appropriate. There
>> is also no need for USE="qt" anymore.
>>
>> To achieve this, version 3 of gtk should always be enabled by
>> USE="gtk3". At some point in the future, when gtk2 consumers
>> reach zero, we will retire "gtk" for good. Then, if some day gtk4
>> comes around, we will be able to introduce support for it in the
>> tree by simply adding USE="gtk4", without having to re-structure
>> half the tree.
>>
>> We are reaching out to the developer community to hear your
>> thoughts and ideas on the matter. We would like to reach a
>> decision that could possibly affect and direct the state of whole
>> tree. This decision could then be turned into a policy, improving
>> Gentoo's consistency across the tree.
>
> Imho the whole discussion stems for packages maintainers which, as
> you have written, did not follow our recommendation and tried to
> provided application with both gtk2 and gtk3 support.
>
> I agree that "Gentoo is about choice..." however as a maintainer of
> a lot of packages, it is unreasonable to try to support two
> configuration where one is dying slowly due to upstream (gtk)
> maintainer focus being elsewhere, hence why we wanted maintainers
> to choose. Instead, it occurs that some decided not to choose or to
> stop users from annoying them with 100 of duplicate bugs about not
> providing the alternative.
>
> Looking at the situation from a gnome team member perspective when
> Gnome 3 was introduced to the tree, only three packages (providing
> libs) needed exception to the rule to avoid unreasonable
> maintenance overhead: spice, gtk-vnc and avahi. All of them had
> proper USE-dependencies in relevant ebuilds so no confusion would
> be possible.
>
> Right now, I don't really get the point of this discussion given
> all the precedent threads about this, be it 2 years ago and 8-10
> years ago.
>
> Anyway, if QA would provide with a list of "offenders" (this could
> have been done on bugzilla btw), we could walk-through the list and
> verify what/if/how packages would need extra USE flags or not and
> not just for our self-written policy's sake that is.
>
>> Cheers
>>
>> [0]
>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014
>>
>>
[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iKYEARECAGYFAlL6wUJfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1Q2IACeOB96oRQ5Q0xPrmSumpHePAs8
j/wAmwZYD20RaNaswb8rzRQCyqTw9ya9
=tQvv
-----END PGP SIGNATURE-----
