info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
51 views
Skip to first unread message
Alex Alexander
Feb 11, 2014, 5:40:02 PM2/11/14
to
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
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
Samuli Suominen
Feb 11, 2014, 6:10:02 PM2/11/14
to
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).
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]
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.
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.
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
documenting common sense.
Gilles Dartiguelongue
Feb 11, 2014, 6:20:01 PM2/11/14
to
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 <e...@gentoo.org>
Gentoo
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).
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]
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.
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
--
Gentoo
Ulrich Mueller
Feb 11, 2014, 7:00:02 PM2/11/14
to
>>>>> 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
> 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.
libraries. If a program supports more than one toolkit, then the
choice should be left to the user. Nothing redundant there.
Ulrich
Samuli Suominen
Feb 11, 2014, 7:10:01 PM2/11/14
to
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
Ulrich Mueller
Feb 11, 2014, 7:30:03 PM2/11/14
to
>>>>> 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
> 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
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
Chris Reffett
Feb 11, 2014, 7:40:03 PM2/11/14
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
-----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-----
Hash: SHA1
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.
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-----
Ryan Hill
Feb 12, 2014, 1:30:02 AM2/12/14
to
On Tue, 11 Feb 2014 19:33:06 -0500
Chris Reffett <cref...@gentoo.org> 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
Chris Reffett <cref...@gentoo.org> 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.
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
Lars Wendler
Feb 12, 2014, 2:30:02 AM2/12/14
to
Hi,
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
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
Pacho Ramos
Feb 12, 2014, 2:30:02 AM2/12/14
to
El mar, 11-02-2014 a las 19:33 -0500, Chris Reffett escribió:
[...]
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)
[...]
> 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,
> 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.
>
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)
Gilles Dartiguelongue
Feb 12, 2014, 3:20:02 AM2/12/14
to
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
> 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.
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
Feb 12, 2014, 3:20:02 AM2/12/14
to
Le mercredi 12 février 2014 à 08:29 +0100, Lars Wendler a écrit :
[...]
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.
[...]
>
> 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
> 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.
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.
Michał Górny
Feb 12, 2014, 3:20:03 AM2/12/14
to
Dnia 2014-02-12, o godz. 00:39:14
Alex Alexander <wi...@gentoo.org> 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
Alex Alexander <wi...@gentoo.org> 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.
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.
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.
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
Michał Górny
Feb 12, 2014, 3:20:03 AM2/12/14
to
Dnia 2014-02-11, o godz. 19:33:06
Chris Reffett <cref...@gentoo.org> napisał(a):
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.
Chris Reffett <cref...@gentoo.org> napisał(a):
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.
Tom Wijsman
Feb 12, 2014, 4:20:02 AM2/12/14
to
On Wed, 12 Feb 2014 09:05:59 +0100
Michał Górny <mgo...@gentoo.org> wrote:
> Dnia 2014-02-12, o godz. 00:39:14
> Alex Alexander <wi...@gentoo.org> 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
Michał Górny <mgo...@gentoo.org> wrote:
> Dnia 2014-02-12, o godz. 00:39:14
> Alex Alexander <wi...@gentoo.org> 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.
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.
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'.
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.
"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.
[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.
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.
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.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : Tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Chris Reffett
Feb 12, 2014, 5:50:01 PM2/12/14
to
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
Gilles Dartiguelongue
Feb 12, 2014, 7:00:02 PM2/12/14
to
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
> 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
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.
Matt Turner
Feb 12, 2014, 7:30:02 PM2/12/14
to
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.
Ryan Hill
Feb 12, 2014, 7:50:02 PM2/12/14
to
On Wed, 12 Feb 2014 09:10:31 +0100
Gilles Dartiguelongue <e...@gentoo.org> 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
Gilles Dartiguelongue <e...@gentoo.org> 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.
install multiple SLOTs of the same version of a package is a fucking
travesty.
Ben de Groot
Feb 18, 2014, 4:40:02 AM2/18/14
to
On 12 February 2014 07:04, Samuli Suominen <ssuo...@gentoo.org> wrote:
[...]
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
[...]
>
> 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.
>
[...]
> 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.
> Just make the gnome gtk3 policy the guideline if you must. It's just
> documenting 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
Sergey Popov
Feb 19, 2014, 12:50:02 PM2/19/14
to
18.02.2014 13:39, Ben de Groot пишет:
We definitely NEED the policy, cause if we do not - current situation
will continue to confuse users and even developers about how to do
things properly.
But we should come to the policy together and then - force it together.
We really do not want to force anyone in a way he does not like, but if
we will do nothing about this - it will remain a problem as it is now.
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
will continue to confuse users and even developers about how to do
things properly.
But we should come to the policy together and then - force it together.
We really do not want to force anyone in a way he does not like, but if
we will do nothing about this - it will remain a problem as it is now.
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
Donnie Berkholz
Feb 20, 2014, 10:30:02 PM2/20/14
to
On 00:13 Wed 12 Feb , Gilles Dartiguelongue wrote:
> 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.
I spent a while tonight digging up this post from 2005, which nicely
> 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.
describes where we were with gtk1 vs gtk2 back then.
http://marc.info/?l=gentoo-dev&m=111212920310822&w=2
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>
0 new messages