RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Alex Alexander
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).

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]

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.

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
--
Alex Alexander | wired@gentoo

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Samuli Suominen-4

On 12/02/14 00:39, Alex Alexander wrote:
> 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).

No, it has always meant the latest version, it dates back to when gnome1
was still in tree

>
> 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]

USE="gtk3" is valid only for libraries when it's not easy to split/slot
as a temporary flag.
Applications should simply pick one, the latest one that works, since
anything else is
obviously redudant.

>
> 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.

It's sad that people don't follow common sense (which happens to be the
GNOME highlights)
and that everything must be turned into a policy of somesort so people
get it.

>
> 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.

I don't understand how unversioned flag could make things worse when
it's as straightforward
it can get -- gtk3 is a version bump over gtk2, if application supports
gtk3, it's
the one that should be used. The temporary USE="gtk3" used in some
packages due to
difficulties of splitting/slotting the packages, goes away soon enough.
What's important that the disease doesn't spread across the tree, making
it's life unnecessarily longer.

>
> 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.
>
> 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

Just make the gnome gtk3 policy the guideline if you must. It's just
documenting common sense.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Gilles Dartiguelongue-3
In reply to this post by Alex Alexander
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.

> 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

--
Gilles Dartiguelongue <[hidden email]>
Gentoo

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Ulrich Mueller-2
In reply to this post by Samuli Suominen-4
>>>>> On Wed, 12 Feb 2014, Samuli Suominen wrote:

> USE="gtk3" is valid only for libraries when it's not easy to
> split/slot as a temporary flag. Applications should simply pick one,
> the latest one that works, since anything else is obviously
> redudant.

I don't see why applications should be treated differently from
libraries. If a program supports more than one toolkit, then the
choice should be left to the user. Nothing redundant there.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Samuli Suominen-4

On 12/02/14 01:51, Ulrich Mueller wrote:

>>>>>> On Wed, 12 Feb 2014, Samuli Suominen wrote:
>> USE="gtk3" is valid only for libraries when it's not easy to
>> split/slot as a temporary flag. Applications should simply pick one,
>> the latest one that works, since anything else is obviously
>> redudant.
> I don't see why applications should be treated differently from
> libraries. If a program supports more than one toolkit, then the
> choice should be left to the user. Nothing redundant there.
>
> Ulrich

For libraries it's forced, like eg. libcanberra's gtk3 version for GNOME
and gtk2
version for Xfce due to direct use of NEEDED, headers, pkg-config etc.

But applications is whole different story...

The maintainer makes the decision which toolkit is used and best supported.
If some application has initial port to gtk3, but still lacks some
features the gtk2
version still had, then maintainer makes the smart choice of using the
version
that has all the features, if the maintainer deems those features important.
There is no point in having them in parallel, it only increases the
workload,
making maintainer do double-testing of the application, not to mention the
work it causes later when gtk2 is slated obsolete as gtk1 is now

Sometimes I think people have already forgotten the mess we had during the
gnome1 removal times with USE="gtk2" :-(

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Ulrich Mueller-2
>>>>> On Wed, 12 Feb 2014, Samuli Suominen wrote:

> But applications is whole different story...

> The maintainer makes the decision which toolkit is used and best
> supported. If some application has initial port to gtk3, but still
> lacks some features the gtk2 version still had, then maintainer
> makes the smart choice of using the version that has all the
> features, if the maintainer deems those features important. There is
> no point in having them in parallel, it only increases the workload,
> making maintainer do double-testing of the application, not to
> mention the work it causes later when gtk2 is slated obsolete as
> gtk1 is now

Let's take Emacs as an example. The upstream package supports Athena
widgets (both in Xaw and Xaw3d variants), Motif, GTK2, and GTK3.
Currently there are five USE flags to control this, and I'm convinced
that the right solution is to leave this choice to the user.

(And if I was forced to decide on the toolkit for Emacs, then I
wouldn't even pick GTK, for stability reasons ...)

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Chris Reffett-3
In reply to this post by Gilles Dartiguelongue-3
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Ryan Hill-3
On Tue, 11 Feb 2014 19:33:06 -0500
Chris Reffett <[hidden email]> wrote:

> 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.
Exactly.  For wxGTK my options are using a gtk3 USE flag, adding a whole new
wxGTK-gtk3 ebuild, or using a 3.0-gtk3 SLOT and some clumsy -r300 thing.
The second option brings along a nightmare of file collisions (we have enough
trouble supporting multiple installed versions, never mind multiple toolkits
within those versions), and the last option isn't actually feasible because
everything in the eclass/eselect is tied directly into the SLOT.


--
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Pacho Ramos
In reply to this post by Chris Reffett-3
El mar, 11-02-2014 a las 19:33 -0500, Chris Reffett escribió:
[...]

> 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.
>

At least for webkit-gtk, we would still need to have slots as,
otherwise, people wanting gtk2 support wouldn't be able to have webkit2
support at the same time (that is needed by, for example, epiphany and
other recent webkitgtk consumers), not sure about other slotted packages
for gtk2/3 support (I don't have much time just now to recheck all :S)




Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Lars Wendler
In reply to this post by Alex Alexander
Hi,

On Wed, 12 Feb 2014 00:39:14 +0200 Alex Alexander wrote:

>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).
>
>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]
>
>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.
>
>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

This is a really good idea and I am all in favor of it.
gtk+:3 still isn't adopted widely and there are still not many good
looking skins available for it. (sorry but I don't want to have all gtk+
apps I am using looking totally ugly again)
I doubt gtk+:2 will be deprecated that soon as some of our devs try
to imply.


--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Michał Górny-5
In reply to this post by Alex Alexander
Dnia 2014-02-12, o godz. 00:39:14
Alex Alexander <[hidden email]> napisał(a):

> 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.

First of all, I think that the policy on a flag related to GTK+ should
be set by the GTK+ maintainer, that is the GNOME team, and not directly
by QA.

If people dislike the policy set by GNOME, they can appeal to QA, sure.
But IMO afterwards QA should either give their blessing to the current
GNOME policy or tell GNOME to change the policy, not step in front of
them with a 'higher instance override'.

> 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.

How does the flag exactly do that? I don't seem to get the point
in that paragraph.

> 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.

This goes exactly against the policy that is being established e.g. for
USE=ssl. If QA is really supposed to set a policy here, it should set
a generic policy for all those cases.

USE flags should represent *features*, not tools used to implement
them. If users want SSL support in an application, they want to set
USE=ssl and stop caring. Not look through all the USE flags in case
application used USE=openssl, USE=gnutls, USE=polarssl etc. for it.

Multiple USE flags make sense when there's support for multiple
toolkits that works and is maintained, and the user may reasonably want
to switch between them. But then, the extra USE flags for toolkit
switching should be introduced with keeping USE=ssl as the generic
on/off switch and the specific flags an optional implementation switch
for power users.

In the end, GTK+ is much the same. You want GTK+ GUI, you enable
USE=gtk. You need specific switching between 2 and 3, assuming it is
*reasonable and well supported*, you can use extra USE=gtk2 or
USE=gtk3. This generally works, and causes issues mostly to complainers
alike 'I dislike this, I want to be able to easily mask it all'.
I don't think there's a point messing up the general case for the sake
of complainers that will either end up enabling USE=gtk3 anyway at some
point or end up without a GUI.

That said, I'm all for killing most of USE=gtk, USE=wxwidgets, USE=qt*
occurrences with a generic USE=gui following the earlier principle.
If user installs an application and wants a GUI for it, shklee
shouldn't have to care whether it's GTK+, wxWidgets or Qt. Gentoo
should be a distribution friendly to all toolkits, people who collect
applications specific to a single toolkit belong in {,k,x}ubuntu.
Then, the special USE flags make sense for fine-picking one
of the toolkits when multiple are supported.

--
Best regards,
Michał Górny

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Michał Górny-5
In reply to this post by Chris Reffett-3
Dnia 2014-02-11, o godz. 19:33:06
Chris Reffett <[hidden email]> 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.

--
Best regards,
Michał Górny

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Gilles Dartiguelongue-3
In reply to this post by Chris Reffett-3
Le mardi 11 février 2014 à 19:33 -0500, Chris Reffett a écrit :

> 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.
And here comes the "version abuse" troll again. This discussion was
settled months ago by exhaustion so please do not try to put some
gasoline on it.

Most packages we have been confronted to chose to only support gtk2 or
gtk3 and if in their history the supported gtk2 then gtk3, we need a
slot for that because it makes sense. See gnome-desktop, glade, gtkhtml,
at-spi, libgda, gucharmap, vte, etc.

For those packages that still support both actively, we still want slots
because most packages we have seen (webkit-gtk, gtk-vnc, spice and more
that since lost their gtk2 support) only allowed building against one
toolkit at a time.

--
Gilles Dartiguelongue <[hidden email]>
Gentoo

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Gilles Dartiguelongue-3
In reply to this post by Lars Wendler
Le mercredi 12 février 2014 à 08:29 +0100, Lars Wendler a écrit :
[...]
>
> This is a really good idea and I am all in favor of it.
> gtk+:3 still isn't adopted widely and there are still not many good
> looking skins available for it. (sorry but I don't want to have all gtk+
> apps I am using looking totally ugly again)
> I doubt gtk+:2 will be deprecated that soon as some of our devs try
> to imply.

We do not pretend anything, we read upstream statements in bug reports
and in blogs. I do not keep them bookmarked though but do not get your
hopes too high, it will be slow, but as sure as Gnome 2 is going to be
removed from the tree, gtk2 is not evolving anymore and receives as
little maintenance as possible by upstream (which in software
development means it is rusting and the conclusion should be evident to
anyone).

Of course, just as gtk1 we are not going to remove it right now.

--
Gilles Dartiguelongue <[hidden email]>
Gentoo

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Tom Wijsman-2
In reply to this post by Michał Górny-5
On Wed, 12 Feb 2014 09:05:59 +0100
Michał Górny <[hidden email]> wrote:

> Dnia 2014-02-12, o godz. 00:39:14
> Alex Alexander <[hidden email]> napisał(a):
>
> > 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.
>
> First of all, I think that the policy on a flag related to GTK+ should
> be set by the GTK+ maintainer, that is the GNOME team, and not
> directly by QA.
The GNOME team has already made a recommendation on this; and feel free
to correct me, but I think they internally regard it as a policy the
GNOME team itself has to apply.

> If people dislike the policy set by GNOME, they can appeal to QA,
> sure.

This is what indirectly happens here; hasufell brought this up to us,
as people are closing bugs blocking below tracker as RESOLVED WONTFIX:

    https://bugs.gentoo.org/show_bug.cgi?id=420493

An overview of the bugs blocking this tracker:

    https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL%20blocked%3A420493

> But IMO afterwards QA should either give their blessing to the
> current GNOME policy or tell GNOME to change the policy, not step in
> front of them with a 'higher instance override'.

We've brought leio early into the discussion during the QA team
meeting; as it currently stands, I think this is still a recommendation
which makes it easier for people to object it.

We've planned to bring this out to the mailing list (as wired did), as
well as clarify the objections to it; in an attempt to listen and then
discuss and work with the GNOME team on making this work for everyone.

> > 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.
>
> How does the flag exactly do that? I don't seem to get the point
> in that paragraph.

What do we think the flag does? There are multiple ways to interpret
"gtk - Add support for x11-libs/gtk+ (The GIMP Toolkit)" if you want
to; and depending on that, there are underlying difficulties that pop
up. Does it cover one slot or all slots? If it covers one slot, should
it be named after that slot instead? If it covers multiple slots,
quoting leio: Why don't we just rename it to USE="gui"?

Other people more acknowledged with that can probably explain it more
well, but realistically the USE flag description should explain this
more clear such that we don't need to explain it; now, consider this:

    Why is there no USE="qt" for Qt? Why do we not need it there?

> > 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.
>
> This goes exactly against the policy that is being established e.g.
> for USE=ssl. If QA is really supposed to set a policy here, it should
> set a generic policy for all those cases.
>
> USE flags should represent *features*, not tools used to implement
> them. If users want SSL support in an application, they want to set
> USE=ssl and stop caring. Not look through all the USE flags in case
> application used USE=openssl, USE=gnutls, USE=polarssl etc. for it.
Exactly, I think this backs up the USE="gui" idea above.

[TL;DR: Skip the next two paragraphs, we're agreeing on that; I just
left it in for if anyone wants to read it for furtherer understanding.]

As for the versioned USE="gtk3", ...; I'm wondering how the user would
then specify what to build for, or even worse: If a package depends on
gtk+ without a SLOT and was build against gtk3, then the user wants to
support gtk4 as well but hold on to gtk3 until all his packages work
with gtk4, how would you reflect that in the ebuild?

I see USE="gtk" --> USE="gui" as a good idea; however, for a reason
like the above where control as to which GTK version is supported
(benefits changed USE flag rebuilds) is needed by the user are affected
if we decide to do something about the versioned USE="gtk3", ...

> Multiple USE flags make sense when there's support for multiple
> toolkits that works and is maintained, and the user may reasonably
> want to switch between them. But then, the extra USE flags for toolkit
> switching should be introduced with keeping USE=ssl as the generic
> on/off switch and the specific flags an optional implementation switch
> for power users.
>
> In the end, GTK+ is much the same. You want GTK+ GUI, you enable
> USE=gtk. You need specific switching between 2 and 3, assuming it is
> *reasonable and well supported*, you can use extra USE=gtk2 or
> USE=gtk3.
Sorry; should have read further before writing my previous quote
response, there's agreement here to a large extent as you can see by
the previous two paragraphs.

> This generally works, and causes issues mostly to complainers alike
> 'I dislike this, I want to be able to easily mask it all'. I don't
> think there's a point messing up the general case for the sake of
> complainers that will either end up enabling USE=gtk3 anyway at some
> point or end up without a GUI.
>
> That said, I'm all for killing most of USE=gtk, USE=wxwidgets, USE=qt*
> occurrences with a generic USE=gui following the earlier principle.

This last sentence (especially the * on qt) makes me wonder if we fully
agree though; as put out in the two paragraphs I told you to skip, this
takes a bit of control away from the user which some users might want.

Also seems you are already aware of USE="gui" (or came up with it too).

> If user installs an application and wants a GUI for it, shklee
> shouldn't have to care whether it's GTK+, wxWidgets or Qt. Gentoo
> should be a distribution friendly to all toolkits, people who collect
> applications specific to a single toolkit belong in {,k,x}ubuntu.
> Then, the special USE flags make sense for fine-picking one
> of the toolkits when multiple are supported.

Yes; in this context, users can mask what they want to avoid.

--
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : [hidden email]
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Chris Reffett-3
In reply to this post by Michał Górny-5
On 2/12/2014 3:09 AM, Michał Górny wrote:

> Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett
> <[hidden email]> 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). I also fail to see what
this has to do with binpkgs: if something needs webkit-gtk[gtk2], you
add a dep on webkit-gtk[gtk2]. The user adds USE=gtk2 to webkit-gtk if
needed, webkit-gtk binpkg gets rebuilt. I see no breakage there.

Chris Reffett

Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Gilles Dartiguelongue-3
Le mercredi 12 février 2014 à 17:46 -0500, Chris Reffett a écrit :
> 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). I also fail to see what
> this has to do with binpkgs: if something needs webkit-gtk[gtk2], you
> add a dep on webkit-gtk[gtk2]. The user adds USE=gtk2 to webkit-gtk if
> needed, webkit-gtk binpkg gets rebuilt. I see no breakage there

Actually changing a USE flag on a package such as webkit-gtk has a huge
cost.

If say you build with USE=gtk3 then suddenly need gtk2, you not only
build what you need, you will also have to rebuild gtk3 support which
you already have though. Since this takes a decent amount of time, even
on a one year old i7, I don't know about you, but I am pretty sure users
will start to complain about this as well.

You would have to build, webkit1 for gtk2, webkit1 for gtk3 and webkit2
for gtk3.

The story is the same for almost all libs that support both toolkits,
you end up rebuilding everything even if you already have one.
webkit-gtk is just the best example to prove you this is a bad idea.

--
Gilles Dartiguelongue <[hidden email]>
Gentoo


Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Matt Turner-5
In reply to this post by Chris Reffett-3
On Wed, Feb 12, 2014 at 2:46 PM, Chris Reffett <[hidden email]> wrote:

> On 2/12/2014 3:09 AM, Michał Górny wrote:
>> Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett
>> <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Ryan Hill-3
In reply to this post by Gilles Dartiguelongue-3
On Wed, 12 Feb 2014 09:10:31 +0100
Gilles Dartiguelongue <[hidden email]> wrote:

> Le mardi 11 février 2014 à 19:33 -0500, Chris Reffett a écrit :
> > 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.
>
> And here comes the "version abuse" troll again. This discussion was
> settled months ago by exhaustion so please do not try to put some
> gasoline on it.
Using arbitrary revision numbers to make up for the fact that you can't
install multiple SLOTs of the same version of a package is a fucking
travesty.


--
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

Ben de Groot-2
In reply to this post by Samuli Suominen-4
On 12 February 2014 07:04, Samuli Suominen <[hidden email]> wrote:
[...]
>
> It's sad that people don't follow common sense (which happens to be the
> GNOME highlights)
> and that everything must be turned into a policy of somesort so people
> get it.
>
[...]
>
> Just make the gnome gtk3 policy the guideline if you must. It's just
> documenting common sense.
>

It seems that only the Gnome team regards this as common sense.
Others, such as the Qt team and QA regard the versioned useflag
solution as more sensible.

I think we can conclude that there is no perfect solution, and we
simply have different preferences.

That said, I'm not sure we absolutely need a policy. Though I would
agree it would be more elegant if we can solve this matter, to make it
easier to grasp by our users. In that case the QA proposal makes sense
to me.

--
Cheers,

Ben | yngwin
Gentoo developer

12