Re: [gentoo-dev] www-client/chromium gtk3 support

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/09/2015 12:20 AM, Paweł Hajdan, Jr. wrote:
> A user asked for optional gtk3 support in www-client/chromium:
> <https://bugs.gentoo.org/show_bug.cgi?id=559378>
>
> However, reading e.g.
> <https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies
#gtk3>
>
>
says this:
>
>> having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is
>> forbidden
>
>> package is an application with support for multiple gtk+,
>> maintainer is free to select whatever slot he desires to support.
>> It is strongly advised to use gtk+-3 if functionality is
>> equivalent. This is to reduce workload of bugs being triggered
>> with one slot but not the other.
>
> What are your recommendations for the best course of action?
>
> For stability and maintainability, I'd prefer www-client/chromium
> to use the upstream defaults (gtk+-2 AFAIK) since it's most common,
> tested, and supported configuration. If/when upstream moves to
> gtk+-3, we'd just follow.
>
> I also understand we have users who are eager to run various
> configurations, and expect Gentoo to be flexible and allow that.
> Would masking a gtk3 USE flag for www-client/chromium be
> acceptable? Are there any other solutions that might work?
>
> Paweł
>
x11-misc/spacefm supports multiple toolkits as well. I stay in line
with GNOME suggestions by making gtk3 the default, but gtk2
configurable via USE. Versioned USE flags are generally frowned upon,
but I see no better way to support both a GTK3 default *and* allow for
the GTK2 support. Part of the reason I came to Gentoo (and became a
dev) is to support user choice, and personally as a maintainer that
matters more than suggestions.

If the GNOME team has a solid recommendation for supporting both GTK2
and 3, I'll read it. But for now, defaulting IUSE to gtk3 and allowing
the user to set gtk2 is the best of both worlds imo.

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV797CAAoJEAEkDpRQOeFwcl4P+wUAQwjoVCdvEjELYxSpgHZS
I6xd+YOikyRuio68+UB1pBeJpFkZkblQ7DS6loK8eIQFSM+C3RQ1bM2Qa/iQ7he4
4X5NNDVMI8UgT568TsH0d6k/AuUxGuRlH6lrMKOdXZfrCen/pl0QLTtWkI+sOzh4
hAxDKoXf3CntmIrwCp2bsTDyU79uX+X2mQHnjz49U7FXYWc+WDPMaFK1dQzp59wD
vLnMFNoh27gVSWNwsYiy6yo7hL73vIF2ZQaiYnQDKR3nxOLvWLTsCY6JSfebSJiX
bv/dyUldcjK4vaEaES0+PYHVww7A3f13QbC3b3/8oTxAHfMZpYCWnskUN1hCx337
I+/LBR2KrSsoyLPNNfMuVk0t4h2TEQw2SHED4+ObQ2qQ4tc1SmdWPn3g//2e8cFU
Zl2fLxfrXiQxCUB5dByUXSzD1lPCo7BvespewoJ3g+YkeZpxfQ4iyt91otG8sooW
VNJF/+gqgBSGnJPZQBjx1n6bjx08B++pCoybvZGn2NUHvLpYe/rgA3oZyg0clZND
dEbkgXbbn3dJMbiaTzT7ou2Icv0T0F7+xHxq4IFvZ7NgthrNhmTFllWsgC0rpM3/
RLwjFfaekap1utGew5W3+77xyKIxDIeBFGQm0pP7KgQDHn+M6Cs5+r64vljDXsWp
0MYg19z2jBdxbCpaMxET
=Q16B
-----END PGP SIGNATURE-----

[Paweł Hajdan, Jr.]

[Andrew Savchenko]

On Wed, 9 Sep 2015 00:24:55 -0700 Daniel Campbell wrote:
> > For stability and maintainability, I'd prefer www-client/chromium
> > to use the upstream defaults (gtk+-2 AFAIK) since it's most common,
> > tested, and supported configuration. If/when upstream moves to
> > gtk+-3, we'd just follow.
> >
> > I also understand we have users who are eager to run various
> > configurations, and expect Gentoo to be flexible and allow that.
> > Would masking a gtk3 USE flag for www-client/chromium be
> > acceptable? Are there any other solutions that might work?
> >
> > Paweł
> >
> x11-misc/spacefm supports multiple toolkits as well. I stay in line
> with GNOME suggestions by making gtk3 the default, but gtk2
> configurable via USE. Versioned USE flags are generally frowned upon,
> but I see no better way to support both a GTK3 default *and* allow for
> the GTK2 support. Part of the reason I came to Gentoo (and became a
> dev) is to support user choice, and personally as a maintainer that
> matters more than suggestions.
>
> If the GNOME team has a solid recommendation for supporting both GTK2
> and 3, I'll read it. But for now, defaulting IUSE to gtk3 and allowing
> the user to set gtk2 is the best of both worlds imo.

The chromium upstream recommends gtk2, so it should be the default,
even if the GNOME team recommends gtk3.

Best regards,
Andrew Savchenko

[Duncan]

Paweł Hajdan, Jr. posted on Wed, 09 Sep 2015 09:20:13 +0200 as excerpted:

> A user asked for optional gtk3 support in www-client/chromium:
> <https://bugs.gentoo.org/show_bug.cgi?id=559378>

Talking about browsers and gtk3, I read that binary distros are starting
to ship firefox built against gtk3, now.

And with that happened, they'll likely be eager to deprecate gtk2, as I
think firefox was the big hold-out making that impractical.

Which means gentoo will likely eventually follow, since gtk2 viability
will be dropping at that point.

So what's the gentoo gtk3 firefox status, and when it does go gtk3, how
long can users expect their other gtk2 apps to continue to be supported,
if upstream doesn't update to gtk3, due to inactivity or whatever reason?

While I'm at it, what about claws-mail, which I use but which is still
gtk2 based?

And what about pan (nntp client), which I've been long-term involved with
upstream on the mailing lists as a "guru user" and kept the list lights
on when there was effectively no upstream dev, so I happen to know its
gtk3 status fairly well -- the gtk3 port has long been done and some
distros even ship it, but we continue to recommend gtk2 because we
continue to get reports of various gtk3-based pan bugs that "magically"
disappear when people rebuild with gtk2, that have never been traced much
further than that, because the recommendation continues to be gtk2 (yes,
circular reasoning, but...).

And for as long as I've been running pan, nearing a decade and a half
now, development has always been sporadic, as I said even lacking an
upstream dev at all, for a few years. A couple years ago Heinrich
Mueller adopted it and did a lot of work, adding some features that had
been on the request list for years, but while he (and Petr Kovar, the
Gnome rep and website maintainer, but a l10n guy not a dev) still do
patches, he hasn't done much more than that for a couple years. So
realistically, upstream isn't going to be very active in getting those
gtk3 bugs traced and patched, tho patches will probably be applied if
distro maintainers develop and submit them.

For the desktop I tend to be more a kde guy (tho I'm not sure I will
still be with the frameworks5/plasma5 upgrade...), but on these apps, and
particularly on pan, since I /am/ involved with upstream there, I'm
concerned about gtk, but am not close enough to the gentoo/gtk team to
know the status there, thus the questions.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

[hasufell]

On 09/09/2015 09:24 AM, Daniel Campbell wrote:
>
> x11-misc/spacefm supports multiple toolkits as well.

It shouldn't. Gtk3 is stable and gtk2 and gtk3 USE flags should be
removed to be consistent with the rest of the tree.

[Brian Dolbec]

to hell with stable, IMHO gtk3 is just crap and nearly destroys all
usability, I have mostly gtk2, with some gtk3, and I'd love to nuke
the rest of the gtk3 ones... So, if chromium goes gtk3, I'll be
looking for a new browser. and if gentoo drops gtk2, I'll be looking
for a new DE...

--
Brian Dolbec <dolsen>

[hasufell]

I haven't encountered a gtk app (I develop some myself) that has dropped
significant features in the process of migration to gtk3, but I
obviously don't use all of them.

IMO, there's pretty much no difference for the user, except that the
codepaths are better maintained.

You can have the exact same usability with gtk3 as with gtk2. That's
developer choice, not toolkit related. When upstream developers drop
features or even toolkit support, you don't want to ship legacy code to
the user.

So this is just a transition period anyway and we shouldn't confuse our
users with temporary USE flags that break consistency, unless that's
absolutely necessary.

Again: usability is not predefined in the toolkit. This is not about gnome3.

[Alexandre Rostovtsev]

On Wed, 2015-09-09 at 09:20 +0200, Paweł Hajdan, Jr. wrote:

In chromium's case (a new gtk3-based ui that needs wider testing), a
local gtk3 USE flag does make sense.

But in general, the gnome team recommends avoiding the gtk3 flag
whenever possible. We definitely don't want it to become a global flag.
We are trying to avoid the following scenario:

(1) Dozens of ebuilds add gtk3 USE flag, and the semantics of the gtk3
flag differ wildly in those ebuilds:
(a) build an optional gui that happens to be based on gtk3 (instead
of no gui at all);
(b) build experimental gtk3-based gui (instead of stable gtk2 gui as
recommended by upstream);
(c) build recommended gtk3-based gui (instead of legacy gtk2-based
gui which is not supported by upstream any more);
(d) build widget library and utilities for gtk3 (possibly in parallel
with gtk2 widgets and utilities);
(e) build widget library and utilities for gtk3 (and disable gtk2
widgets and utilities - without making any effort to allow both
gtk2 and gtk3 support in parallel by splitting the package or
renaming a few files).
(3) Since the flag is used all over the place, some users try to
globally enable or disable it, depending on their personal feelings
about Adwaita's tab shapes.
(4) Since the flag sometimes means "build a gui (instead of no gui at
all)" at some point it gets globally enabled in some profile.
(5) Users are forced to maintain giant lists of package.use entries to
get a usable desktop environment. Unhappiness reigns.

In other words, to avoid the scenario that happened during gtk1/gtk2
transition, and which is now starting with qt4/qt5 [1].

[1] https://archives.gentoo.org/gentoo-dev/message/11e3d077e0d9c953597c3d17f327c6b3

[Mike Gilbert]

I would really like a way to toggle gtk3 for testing. If you don't
want to expose it as a 'supported' option for users, then masking it
sounds fine to me.

[Alexandre Rostovtsev]

On Wed, 2015-09-09 at 11:00 -0400, Mike Gilbert wrote:
> I would really like a way to toggle gtk3 for testing. If you don't
> want to expose it as a 'supported' option for users, then masking it
> sounds fine to me.

Then add the flag, document it in metadata.xml.

But in general, try to avoid using this flag in your ebuilds if
possible, the gnome team *really* doesn't want to turn gtk3 into a
global USE flag with uncertain semantics.

[»Q«]

On Wed, 9 Sep 2015 10:06:30 +0000 (UTC)
Duncan <1i5t5....@cox.net> wrote:

> So what's the gentoo gtk3 firefox status,

Ian or someone can probably give more info, but there are builds in the
mozilla overlay which use gtk3.

> While I'm at it, what about claws-mail, which I use but which is
> still gtk2 based?

I haven't seen any interest from Claws devs to transition to gtk3, but
someone's just cited your post in the bug for it,
<http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2371>.

[Alec Warner]

The best way to avoid this IMHO is to not name the flag the same thing.

if you named the chromium flag "experimental-gtk3-ui' or similar, then users would be unable to turn it on by just setting 'gtk3'

-A

 

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/09/15 06:06 AM, Duncan wrote:
> Paweł Hajdan, Jr. posted on Wed, 09 Sep 2015 09:20:13 +0200 as
> excerpted:
>
>> A user asked for optional gtk3 support in www-client/chromium:
>> <https://bugs.gentoo.org/show_bug.cgi?id=559378>
>
> Talking about browsers and gtk3, I read that binary distros are
> starting to ship firefox built against gtk3, now.
>
> And with that happened, they'll likely be eager to deprecate
> gtk2, as I think firefox was the big hold-out making that
> impractical.

Firefox's use of gtk3 actually still requires gtk2, so gtk2 won't be
deprecated (at least not any time soon).

Also, FYI, since gtk2 will (for the forseeable future) always be
required by the firefox core, we are going to add a gtk3 flag to
provide end-user control of building the frontend against gtk3 or not.

I don't think deprecation of gtk2 is anything we are going to need
to worry about any time soon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXwUQcACgkQAJxUfCtlWe1r4QEAwJ4VQLTQhHe9Mx6DocDtkk0k
TXYlocHSXPqrb907jx8BANABAaCToAOPnKchenrMLJxQFh0euC1Ku0ki8H9TwJtu
=p0Fr
-----END PGP SIGNATURE-----

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Is it worth noting that there are dozens of packages in the tree
right now that have a gtk3 flag in IUSE? Many have 'gtk gtk3'
combinations, and many others have 'gtk3' entirely on their own:

app-editors/emacs
app-editors/emacs-vcs
app-editors/mousepad
app-i18n/fcitx
app-i18n/fcitx-configtool
app-i18n/ibus
app-i18n/ibus-unikey
app-i18n/imsettings
app-i18n/scim
app-i18n/scim-anthy
app-i18n/uim
app-misc/emelfm2
dev-libs/libdbusmenu
dev-python/matplotlib
dev-util/geany
kde-plasma/plasma-desktop
lxde-base/lxdm
mail-client/claws-mail
media-gfx/geeqie
media-libs/libcanberra
media-plugins/audacious-plugins
media-sound/audacious
media-sound/easytag
media-sound/mp3splt-gtk
net-analyzer/pinger
net-dns/avahi
net-libs/gtk-vnc
net-misc/dhcpcd-ui
net-misc/electrum
net-misc/spice-gtk
www-client/dwb
www-client/uget
www-client/uzbl
www-client/vimb
www-plugins/freshplayerplugin
x11-drivers/nvidia-drivers
x11-misc/light-locker
x11-misc/spacefm
x11-themes/light-themes
xfce-base/libxfce4ui
xfce-extra/xfce4-taskmanager

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXwUvcACgkQAJxUfCtlWe3oBgEAvr7nBfDygUPG4MGiK23ya3Xn
RRWLOkprA6SuFjbef84BAJehMtEtt+ZqC3HzGJ5yroM+yCqQE855uQz7+2mpGeyC
=LOpM
-----END PGP SIGNATURE-----

[hasufell]

There was a tracker on bugzilla about it at some point, but people
didn't care enough, so I stopped filing bugs. Neither the gnome team nor
QA had a strong enough opinion to enforce consistency here over the
whole tree.

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/09/15 11:48 AM, hasufell wrote:
> On 09/09/2015 05:40 PM, Ian Stakenvicius wrote:
>>

>> [ Snip list ]

>>
>
> There was a tracker on bugzilla about it at some point, but
> people didn't care enough, so I stopped filing bugs. Neither the
> gnome team nor QA had a strong enough opinion to enforce
> consistency here over the whole tree.
>

Right... So, back to the issue at hand. If a package -always-
depends on a gtk (usually gtk2), but can optionally be configured to
depend on gtk3 instead (and it should be optional because support
isn't clearly stable yet), what's the solution here?

IUSE="gtk" isn't appropriate because that's meant for enabling
optional gtk support, not choosing -which- gtk to support when there
always needs to be one. IUSE="gtk3" to me fits well in this case
but it's also reportedly forbidden...
IUSE="experimental-gtk3-support" seems less than optimal but if we
(chromium, mozilla teams) have to go that route I guess we will..

The wiki seems to say that we as rdep maintainers should choose one
and stick with it, but as a mozilla package maintainer, I don't want
to force the entire user base to using one or the other (at least
not yet), given firefox -just- got (that is, will get in two version
bumps) gtk3 support that's considered stable enough for use outside
of development.

I don't suppose we as a community can revisit the decision to ban
IUSE="gtk3" as a flag to toggle between gtk2 and gtk3 support, when
one or the other is -required- by a package?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXwWuYACgkQAJxUfCtlWe25WwD/b8ozgV4zHLyNrIzYI+Cu79+l
gBORP+1q6EMUWyuyVewBAIE3nNFow+XeN67pH4pT6gqQqBJ27VH+bAt9nTprs0pi
=HWeR
-----END PGP SIGNATURE-----

[hasufell]

On 09/09/2015 06:14 PM, Ian Stakenvicius wrote:
>
>
> Right... So, back to the issue at hand. If a package -always-
> depends on a gtk (usually gtk2), but can optionally be configured to
> depend on gtk3 instead (and it should be optional because support
> isn't clearly stable yet), what's the solution here?
>

Provide the gtk3 version in an overlay (without gtk3 USE flag), because
that's where experimental stuff belongs. If people want to test it, they
can do it an we don't have to use ugly stuff like package.use.stable.mask.

[Paweł Hajdan, Jr.]

On 9/9/15 5:48 PM, hasufell wrote:
> There was a tracker on bugzilla about it at some point, but people
> didn't care enough, so I stopped filing bugs. Neither the gnome team
> nor QA had a strong enough opinion to enforce consistency here over
> the whole tree.

Looks like that was <https://bugs.gentoo.org/show_bug.cgi?id=420493> .

I'm not sure whether the underlying issue was enforcement, or just
handling various use cases.

Similar situation with qt/qt4/qt5 seems to confirm to me that it's not
whims that make people not follow the policy, but real needs and use cases.

Quotes from above bug:

> You really have not addressed all the situations here.

> Yes I know there may be situations where the proposed solutions are
> not sufficient.

Also, most blocking bugs seem to be resolved as WONTFIX/WORKSFORME/INVALID.

FWIW I do care. For now responses on this thread seem to recommend (or
be at least OK with) adding gtk3 USE flag to www-client/chromium . If
there's an alternative solution endorsed by GNOME or QA team that would
make progress on <https://bugs.gentoo.org/show_bug.cgi?id=559378>
possible, I'd just switch to that solution.

Paweł

[Duncan]

Ian Stakenvicius posted on Wed, 09 Sep 2015 11:32:23 -0400 as excerpted:

> Firefox's use of gtk3 actually still requires gtk2, so gtk2 won't be
> deprecated (at least not any time soon).

I was entirely unaware of that. Thanks. It changes the picture
dramatically.

> Also, FYI, since gtk2 will (for the forseeable future) always be
> required by the firefox core, we are going to add a gtk3 flag to provide
> end-user control of building the frontend against gtk3 or not.
>
> I don't think deprecation of gtk2 is anything we are going to need to
> worry about any time soon.

Thanks. As I said, firefox-core still requiring gtk2 changes the picture
dramatically, both for gentoo, and as part of pan upstream, for it as
well.

FWIW, there's still some of us that remember the gtk1 based xmms with
fondness for its clean just-what-we-need interface and lack of extraneous
deps, while at the same time providing fancy visualization, etc.
Similarly, there's still those trying to use the kde-sunset overlay for a
kde3 app or two. Personally, I try to be on the (moderately) leading
edge rather than the trailing and was well off of both of these before
they disappeared from the tree, but that's why I'm asking these sorts of
questions (and why I follow this list, as well), giving me as long as
possible to prepare and try to find suitable replacements before I'm
under the gun.

As for pan upstream, I'm on record on the pan lists as saying that until
firefox switches to gtk3, there's not a lot to worry about regarding gtk2,
since firefox really is the big gtk2 elephant in the room and practically
speaking, gtk2 isn't going anywhere until firefox does, either by
switching to something else, or by becoming irrelevant.

With mentions of gtk3 based firefox now in distros and that being my
trigger of record, I was starting to worry about pan on gtk3. But if
firefox still requires gtk2 at its core, the trigger doesn't look to have
actually been pulled, after all. That really /does/ change the picture,
so...

Thanks again! =:^)

[Duncan]

»Q« posted on Wed, 09 Sep 2015 10:12:50 -0500 as excerpted:

> I haven't seen any interest from Claws devs to transition to gtk3, but
> someone's just cited your post in the bug for it,
> <http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?
id=2371>.

Thanks. I've always thought I might at least register with claws'
bugzilla, to CC and track things like this, but never have.

(It'd be nice, sometimes, if every bugzilla instance, let alone other bug
trackers, wasn't a kingdom unto itself, requiring separate registration.
Tho of course centralized has its own problems, including tracking and
privacy implications.)

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

How do you propose packages whose upstreams maintain both gtk2 and
gtk3 builds but don't actively push one over the other be packaged? I
currently have gtk3 and gtk2 flags, but it defaults to gtk3. Should
the gtk3 flag actually be just `gtk` to fall in line with the latest
version, and `gtk2` provide the expected versioned toolkit?

The package in question is a GUI package, so *some* toolkit version
needs to be chosen. Defaulting to gtk3 falls in line with gnome-team's
opinions while still offering gtk2 support. I think limiting it to
*only* gtk3 would be doing our users a disservice.

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV8SMpAAoJEAEkDpRQOeFwzUIQAIMq1BjmnMpevMquOQsoQG4p
uOev7ndC/lyIyV+S0IRyu8QdlVU3iEuMZHDlu6dtz/jJTDTZ6OjC6yQ4NifYd5nE
O16D5u2+diYqpBkCjXo2evLRSvHhMrLt6lmzXkHjJkE4zC1jH3faI6x0keZIro2N
QSaY9pMqfnSET45VuQ632NxgbdZPXc4YpvIty0/AHk86uDuU9aZMyRH6ZpiMp7iu
aGaNyiRXpL1rlRxXD0ppOM6h7gU0MFIAdA1UQqlgbowchX7/T93dBehOXAO3Z38C
ANLEuqPVOqYLaR0P8VLXYUIlusx1tbAUIBSy7ZIyr1s7gUsgi9IkwAAIObsrhf66
oy0MNFS0oiEVrnUYxLyd3XnAKo8XKUFq3ZTn8m41IZKP21fSGyVhmccrhnmXjYv9
k1DC0kMjWPOhtO/8/rdZekoJZYOmXE76HMh74YdMca7DP9E2/WEpuu4P9qUs5EVl
8mjCLZEwTOex96sRt+OiXDxNP0iMA/hllHbdmJsw1BIZhz3wqMi0msUQhmOi2sSt
SZQD+KwonbTYZmEAq2GV0pyEaLO8nC6jCj+vqfAZlrM/IUPKeKFnElNrbORfVqSp
ye/cT4ScmPVpmsEZqB+GizNfX4sue21FHnm7RZpJdIZig2dd9Qjn9LSF0gSwKymK
Zncie7DhlImRSULbsBr4
=13Ur
-----END PGP SIGNATURE-----

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Upstream deliberately supports GTK2 and GTK3 to provide users with
choice. The default choice in the ebuild is gtk3, falling in line with
gnome team's recommendations, but gtk2 is available for those who
prefer it that way.

For me to not support gtk2 in the spacefm ebuild would be providing a
package inferior to upstream. Given the divide among users over the
toolkit, I think it's fair to provide support for both where possible,
but lean in the direction of gtk3 for defaults so the Path of Least
Surprise is maintained.

If you have a better recommendation for allowing both toolkits being
supported, I'd be glad to read it.

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV8SFVAAoJEAEkDpRQOeFw7foP/iwWzIiae3m8N7isfviXsBFs
MQCH0SBlLjDVtTRucXBakTTxt9HUYUrQ3UnNe4ryalPHPZgS8bIC/s2r4S3Sds+o
3q9/jNCaMIKMq5TIu5HzGbIfThMIVslU6+DkDbIxTvN+QPIT+Jn+wmz7ca4K5HV1
LQxJ1+Rgb7Z3bj7yRrwLiGeGRNcbjz4skOJx077Hp0aXpK75706PEVYHftn9yLBM
r6UCY5tPhP7/oMC6tQyV2jvITrJtz4+RkBIJnrUvUA0aewlZskENMq0zSyGLZrCU
z+jf1H+wQQgs7COa+jvdBl4ItPiRJjA141SKjdkhOdRKNXhPNOqP2Ts7h6afpsil
TPZpB91DKE0RjhVxQQBAlnL9KZNF4z7RJ+F18W5mT8qdT/A8J2xeYXczGAKR+jO/
NFyD0IHu+4yvLHQxa8cPhxsxrlCKxrrLn+coKY+jXlouMaDyDaynYqJMZ0i6cXl2
QrGcYogeduLnZf1OvoM9RWk9GbGnKNXR5F0xDCR+BOas6BOGilu44z0QhhPhm0cW
ehXJnKhU76bVLXRDNP71iMir8SoC1E/mD2HTyeRds3nUD7YuflZ6CrBvdmT+P9IG
8LDqW91/uWavgyMGOuXWN5w8rMUR6o1k1ID9/tNbH+JkQepKcs9PGs2tXuPRfOJ8
DnO93xAVLVPXcLu0U251
=ZLIv
-----END PGP SIGNATURE-----

[hasufell]

On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>
> For me to not support gtk2 in the spacefm ebuild would be providing a
> package inferior to upstream.

That sounds like spacefm with gtk3 is lacking anything. It is not.
Providing choice for the sake of choice is not always a good idea.

[Rich Freeman]

Suppose you want to run on an embedded system with limited RAM and the
ability to choose means you can use one of the two libraries
exclusively, thus eliminating the need to load the other library?
Being able to control what libraries are in use is a key feature of
Gentoo, IMO.

--
Rich

[hasufell]

We are not optimizing GUI desktop systems for embedded systems . That's
totally unrealistic and not a real use case.

[Rich Freeman]

Suppose you want to run on a non-embedded system with limited RAM and the

ability to choose means you can use one of the two libraries
exclusively, thus eliminating the need to load the other library?
Being able to control what libraries are in use is a key feature of
Gentoo, IMO.

--
Rich

[hasufell]

On 09/10/2015 02:03 PM, Rich Freeman wrote:
>
> Suppose you want to run on a non-embedded system with limited RAM and the
> ability to choose means you can use one of the two libraries
> exclusively, thus eliminating the need to load the other library?
> Being able to control what libraries are in use is a key feature of
> Gentoo, IMO.
>

Any reference that gtk3 has a higher memory footprint?

[Rich Freeman]

gtk2+gtk3 in RAM at the same time has a higher memory footprint than
either one alone. If any package uses one or the other, it will end
up being loaded into RAM, so there is potentially value in using one
of them exclusively.

I'm not suggesting that package maintainers should be forced to
support both whenever possible. I just don't think they should be
discouraged from doing so.

--
Rich

[hasufell]

On 09/10/2015 02:25 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:13 AM, hasufell <hasu...@gentoo.org> wrote:
>> On 09/10/2015 02:03 PM, Rich Freeman wrote:
>>>
>>> Suppose you want to run on a non-embedded system with limited RAM and the
>>> ability to choose means you can use one of the two libraries
>>> exclusively, thus eliminating the need to load the other library?
>>> Being able to control what libraries are in use is a key feature of
>>> Gentoo, IMO.
>>>
>>
>> Any reference that gtk3 has a higher memory footprint?
>>
>
> gtk2+gtk3 in RAM at the same time has a higher memory footprint than
> either one alone. If any package uses one or the other, it will end
> up being loaded into RAM, so there is potentially value in using one
> of them exclusively.
>

So you are saying for the unlikely case that someone runs gentoo on a
desktop system where he cannot even compile gcc, llvm and others without
waiting for 2 weeks or setting up his on binhost, we have to provide a
backup-path for him, so that gtk3 is not loaded into his RAM?

Do you know what that means if you want to _actually_ (not just
theoretically) support that? You have to do that consistently, not just
for a few packages.

So this makes no sense, since it's already an unsupported corner case.

> I'm not suggesting that package maintainers should be forced to
> support both whenever possible. I just don't think they should be
> discouraged from doing so.
>

Yes, they should be discouraged. It's a QA matter.

[Michael Orlitzky]

On 09/10/2015 08:33 AM, hasufell wrote:
>
> So you are saying for the unlikely case that someone runs gentoo on a
> desktop system where he cannot even compile gcc, llvm and others without
> waiting for 2 weeks or setting up his on binhost, we have to provide a
> backup-path for him, so that gtk3 is not loaded into his RAM?
>

My only laptop runs Gentoo and is ten years old. The CPU is decent but
there's not much RAM and what I do have is shared with the video card. I
don't pay attention to gtk2/gtk3 on it, but it's not hard to imagine
someone would care.

(I can compile GCC just fine in under an hour, you just can't do
anything else at the same time because the whole things locks up and
heats to roughly the temperature of the sun.)

[Alec Ten Harmsel]

On Thu, Sep 10, 2015 at 02:33:09PM +0200, hasufell wrote:
> On 09/10/2015 02:25 PM, Rich Freeman wrote:
> >
> > gtk2+gtk3 in RAM at the same time has a higher memory footprint than
> > either one alone. If any package uses one or the other, it will end
> > up being loaded into RAM, so there is potentially value in using one
> > of them exclusively.
> >
>
> So you are saying for the unlikely case that someone runs gentoo on a
> desktop system where he cannot even compile gcc, llvm and others without
> waiting for 2 weeks or setting up his on binhost, we have to provide a
> backup-path for him, so that gtk3 is not loaded into his RAM?

That was my situation until very recently. Firefox builds took ~6 hours.
gcc took 2-3 hours. Even though gtk is not that big, it still took 15ish
minutes for me to build.

If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild?
From the "I want a usable system with as little code as possible" and "I
want a system tailored to my needs" standpoints, having only one version
of gtk makes quite a bit of sense.

Alec

[Rich Freeman]

On Thu, Sep 10, 2015 at 8:33 AM, hasufell <hasu...@gentoo.org> wrote:
>
> So this makes no sense, since it's already an unsupported corner case.

Just what use of Gentoo do you not consider an unsupported corner
case, which isn't already better supported by some other distro?

The whole point of using Gentoo is having "support" for all those
"unsupported corner cases." If you just want everything to support
doing things in the one way which is most supportable, you're
basically doing a really bad job at re-inventing Debian.

I use quotes around support since all support on Gentoo is
best-effort, and that is all I'm getting at here. If a package
maintainer can support multiple configurations and are willing to do
so, they should be encouraged to do so.

>
>> I'm not suggesting that package maintainers should be forced to
>> support both whenever possible. I just don't think they should be
>> discouraged from doing so.
>>
>
> Yes, they should be discouraged. It's a QA matter.
>

Well, I'm glad we've all aired our opinions on the matter. :)

I just fail to see the QA issue here, unless it again boils down to
that it is easier to do QA when you have one configuration (like
Debian) and not many (like Gentoo).

The other issue that keeps coming up is that we don't have good
standards for USE flag naming in these situations, and the solution to
that is to come up with a good uniform practice.

--
Rich

[hasufell]

On 09/10/2015 02:44 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:33 AM, hasufell <hasu...@gentoo.org> wrote:
>>
>> So this makes no sense, since it's already an unsupported corner case.
>
> Just what use of Gentoo do you not consider an unsupported corner
> case, which isn't already better supported by some other distro?
>
> The whole point of using Gentoo is having "support" for all those
> "unsupported corner cases." If you just want everything to support
> doing things in the one way which is most supportable, you're
> basically doing a really bad job at re-inventing Debian.
>
> I use quotes around support since all support on Gentoo is
> best-effort, and that is all I'm getting at here. If a package
> maintainer can support multiple configurations and are willing to do
> so, they should be encouraged to do so.
>

So we are breaking consistency and introduce maintenance and
configuration complexity, because we want to support a corner case that
isn't consistently supported anyway and will not be (because that's what
the gnome team said and most upstream maintainers do).

You'd actually have to start forking upstream projects if you are
serious about this. Everything else is just fighting the deprecation,
which will come anyway.

I think a lot of people just go wild when they see configure switches
and stuff everything into USE flags without really considering the
impact or the usefulness.

It's not all about choice, it's also about sanity.

[Michał Górny]

Dnia 2015-09-10, o godz. 08:46:41
Alec Ten Harmsel <al...@alectenharmsel.com> napisał(a):

> If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild?
> From the "I want a usable system with as little code as possible" and "I
> want a system tailored to my needs" standpoints, having only one version
> of gtk makes quite a bit of sense.

This is the same case as with many other libraries which suffered major
API changes -- SDL, for example. Just because upstream *thinks* they
support two GTK+ versions, doesn't mean they do. Only one of the
versions is well-tested, and the second one sometimes isn't tested at
all, neither by upstream nor by the developer.

The happy end result is, sometimes user has choice between 'working
package' and 'package randomly segfaulting when you least expect it'.
Of course, it's all hidden nicely under USE=gtk2 and USE=gtk3, so just
*maybe* if you have the time to read local flag descriptions for every
single package you may notice which of the flags should be enabled to
get a working app.

But yes, wasting people's time and offering easy way to data loss is
better than not supporting some imaginary corner case when you can
actually use some fancy combination of applications that can actually
run without that one library without losing stability and benefit you.

I hope you are ready to pay the developers who will waste their time
figuring out what goes wrong when you report a bug, until they figure
out it's because you have forced GTK+ version which upstream thought
they're supporting but they do not. That's certainly a better
alternative than paying for hardware that can handle loading two
libraries.

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[Rich Freeman]

On Thu, Sep 10, 2015 at 8:53 AM, hasufell <hasu...@gentoo.org> wrote:
>
> So we are breaking consistency and introduce maintenance and
> configuration complexity, because we want to support a corner case that
> isn't consistently supported anyway and will not be (because that's what
> the gnome team said and most upstream maintainers do).
>
> You'd actually have to start forking upstream projects if you are
> serious about this.

Again, I'm saying that maintainers should be free to support multiple
versions if they wish to do so. They should not be required to do so.
And yes, I do realize that this limits options for users, but they're
welcome to proxy-maintain packages that do support the versions they
wish to use. If they want to fork upstream they're even welcome to do
that, but obviously that isn't going to happen often.

I just don't think we should be in the business of saying "no" here.

>
> I think a lot of people just go wild when they see configure switches
> and stuff everything into USE flags without really considering the
> impact or the usefulness.
>
> It's not all about choice, it's also about sanity.
>

And again, I'm just saying to leave it up to the maintainer. They can
decide what is sane and what is not.

That is basically how we do everything around here. I can't really
think of that many situations where a maintainer wanted to provide
some kind of configuration and they were forbidden from doing so.
Now, sometimes we might tell them /how/ to provide that configuration
so that it is more consistent across the tree, or so that build
behavior is more deterministic/etc.

> Everything else is just fighting the deprecation,
> which will come anyway.

Everything we do is fighting deprecation. gtk3 will be deprecated
someday, most likely, and yet we're doing all this work to roll it
out.

Maintainers should be free to add value to Gentoo when they feel it is
worth their time to do so. That is basically how we got to where we
are today. Gentoo supports all kinds of stuff that I think is
intellectually interesting but which I'd probably not use personally,
but I'm happy to see it happening all the same and I'm happy that it
is scratching somebody's itch. At the same time, I use Gentoo
features that were added because they scratched somebody else's itch,
even if they weren't thinking about me personally when they did it.

--
Rich

[Rich Freeman]

On Thu, Sep 10, 2015 at 9:07 AM, Michał Górny <mgo...@gentoo.org> wrote:
>
> The happy end result is, sometimes user has choice between 'working
> package' and 'package randomly segfaulting when you least expect it'.
> Of course, it's all hidden nicely under USE=gtk2 and USE=gtk3, so just
> *maybe* if you have the time to read local flag descriptions for every
> single package you may notice which of the flags should be enabled to
> get a working app.

I'd propose that anybody sticking USE=gtk2 or USE=gtk3 in their USE
flags should expect to have a less-supportable system. The problem
isn't the fact that the library is configurable, but rather that we
don't provide users an easy way to just install the package in the
best-supported configuration with a GUI. Users shouldn't have to read
all the local descriptions to figure out how to install a package -
there should be a reasonable default that does what they want. That
doesn't necessitate only supporting a single toolkit version.

This is on the agenda for discussion at the next council meeting, and
has been the subject of numerous threads in various contexts. I think
the biggest problem here is that everybody does things a little
differently. That, and we know a lot more than we did back when devs
were first adding these kinds of versioned flags.

>
> I hope you are ready to pay the developers who will waste their time
> figuring out what goes wrong when you report a bug, until they figure
> out it's because you have forced GTK+ version which upstream thought
> they're supporting but they do not. That's certainly a better
> alternative than paying for hardware that can handle loading two
> libraries.

Again, I'm suggesting this should be up to maintainer's discretion.
If they choose to support two gtk versions, and upstream chooses to do
the same, then why should we worry about filing bugs against a version
they chose to support? If they don't want to support two versions,
they shouldn't.

This seems a bit like arguing that we shouldn't have
package-I-don't-use in the tree because the dev effort required to
support it could be better spent on package-I-use which isn't in the
tree. That sounds nice, but I don't get to dictate what people spend
their time on, and the most we can do from a policy standpoint is
forbid contribution, not force contribution.

--
Rich

[Alan McKinnon]

On 10/09/2015 14:44, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:33 AM, hasufell <hasu...@gentoo.org> wrote:
>>
>> So this makes no sense, since it's already an unsupported corner case.
>
> Just what use of Gentoo do you not consider an unsupported corner
> case, which isn't already better supported by some other distro?
>
> The whole point of using Gentoo is having "support" for all those
> "unsupported corner cases." If you just want everything to support
> doing things in the one way which is most supportable, you're
> basically doing a really bad job at re-inventing Debian.
>
> I use quotes around support since all support on Gentoo is
> best-effort, and that is all I'm getting at here. If a package
> maintainer can support multiple configurations and are willing to do
> so, they should be encouraged to do so.
>
>>
>>> I'm not suggesting that package maintainers should be forced to
>>> support both whenever possible. I just don't think they should be
>>> discouraged from doing so.

+1

I'm fully with Rich here. gtk+2 is out there, it's in the tree and stuff
uses it. Therefore a way must exist for stuff to get to use it.

Everything else is whinging and nattering.

>>>
>>
>> Yes, they should be discouraged. It's a QA matter.
>>
>

Since when does QA devise policy?
QA never devises policy
QA enforces policy that by definition is devised elsewhere

> Well, I'm glad we've all aired our opinions on the matter. :)
>
> I just fail to see the QA issue here, unless it again boils down to
> that it is easier to do QA when you have one configuration (like
> Debian) and not many (like Gentoo).
>
> The other issue that keeps coming up is that we don't have good
> standards for USE flag naming in these situations, and the solution to
> that is to come up with a good uniform practice.

Having gtk, gtk2 and gtk3 USE flags used inconsistently is a problem,
that is not being denied.

What is not a problem is a package that supports one or more toolkits,
offers various ways to implement that support, is supported upstream and
desired by users. That is a fact and as this is not Debian people need
to be willing to let people solve that problem in ways they see fit.
Citing "QA policy" as a way to avoid having to deal with murky real-life
corner cases is just flat out wrong. And those murky corner cases exist,
they always will and are the things that separate real life from
theoretical ideals.

gtk2 exists and is in use. I see no plans to deprecate it globally, so
those who take issue with ugly USE syntax really should learn to deal
with it, or propose a more elegant solution that still accomplishes what
other devs are trying to do.

--
Alan McKinnon
alan.m...@gmail.com

[hasufell]

On 09/10/2015 03:10 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:53 AM, hasufell <hasu...@gentoo.org> wrote:
>>
>> So we are breaking consistency and introduce maintenance and
>> configuration complexity, because we want to support a corner case that
>> isn't consistently supported anyway and will not be (because that's what
>> the gnome team said and most upstream maintainers do).
>>
>> You'd actually have to start forking upstream projects if you are
>> serious about this.
>
> Again, I'm saying that maintainers should be free to support multiple
> versions if they wish to do so. They should not be required to do so.
> And yes, I do realize that this limits options for users, but they're
> welcome to proxy-maintain packages that do support the versions they
> wish to use. If they want to fork upstream they're even welcome to do
> that, but obviously that isn't going to happen often.
>
> I just don't think we should be in the business of saying "no" here.

Again, your proposed use case is
1) imaginary
2) currently impossible to support, because there are lots of
applications which either force gtk3 in the ebuild or have only gtk3
supported upstream. It will be pretty much impossible to not have gtk3
installed or loaded into RAM, unless you don't use a DE in the first
place and stick to terminals.

>
>>
>> I think a lot of people just go wild when they see configure switches
>> and stuff everything into USE flags without really considering the
>> impact or the usefulness.
>>
>> It's not all about choice, it's also about sanity.
>>
>
> And again, I'm just saying to leave it up to the maintainer.

If this affects tree consistency and usability, then it is not just up
to the maintainers.

[Alec Warner]

There are lots of topics where I concede that QA has a point and can utilize its influence; but 'consistency and usability' are not topics I would normally expect them to impose on developers.

-A 

[Rich Freeman]

Well, consistency as far as it involves compliance with standards
(PMS, tree policies, etc) certainly is fair game. I don't think they
always need to be the ones creating the rules, though.

In any case, the whole versioned toolkit (gtk/qt/etc) flag issue is on
the council agenda. I think this is an area that would benefit from a
policy, whether or not I end up agreeing with whatever the policy ends
up being.

Even if we end up deciding to push to not use versioned flags, we may
still end up having them for one-offs, and we'll still need policy on
how to properly control whether the gui gets built or not, and so on.
If we at least have a standard practice things will be easier on
everybody, and this is bigger than any one Gentoo team. Of course
once a policy is established QA should by all means enforce it.

Also, I know that QA tends to get some knee-jerk reactions, but when
QA announces a policy it isn't like this is the end of the
conversation. If you think they're making a mistake, you can always
talk to the QA lead, and appeal to the council. For the most part I
think most of us try to be practical, even if we sometimes create a
mess before we realize what we're getting into.

--
Rich

[Duncan]

hasufell posted on Thu, 10 Sep 2015 10:47:26 +0200 as excerpted:

Nothing personal, but...

Seeing this coming from a gentoo dev, where user choice and control is
viewed as a virtue, is a shame. There's a reason gentoo has USE flags
and doesn't default to binaries.

Particularly where upstream is deliberately providing the choice,
specifically to allow the users that choice, having gentoo abort that
choice seems to stand in the way of everything gentoo and Larry the cow
is about.

(Tho I must say, it does sound like typical upstream gnome think.
Restrict user choice, it's for their own good! I've never understood how
some gentooers could tolerate such an attitude and use gnome as a
preference, as it really is antithetical to gentoo's whole stance on
choice, but of course given that there are devs willing to make it
available, removing gnome as a choice for those who wish to go that way
would be antithetical to that ideal as well, so there you have it.)

[Alec Ten Harmsel]

On Thu, Sep 10, 2015 at 03:07:16PM +0200, Michał Górny wrote:
> Dnia 2015-09-10, o godz. 08:46:41
> Alec Ten Harmsel <al...@alectenharmsel.com> napisał(a):
>
> > If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild?
> > From the "I want a usable system with as little code as possible" and "I
> > want a system tailored to my needs" standpoints, having only one version
> > of gtk makes quite a bit of sense.
>
> This is the same case as with many other libraries which suffered major
> API changes -- SDL, for example. Just because upstream *thinks* they
> support two GTK+ versions, doesn't mean they do. Only one of the
> versions is well-tested, and the second one sometimes isn't tested at
> all, neither by upstream nor by the developer.

I'm sorry, I wrote too briefly. hasufell seems to be saying that gtk2
should be deprecated now. I'm just agreeing with Rich that if upstream
supports both *and* the maintainer wants to support both, there's no
reason to force them to only support one.

> The happy end result is, sometimes user has choice between 'working
> package' and 'package randomly segfaulting when you least expect it'.
> Of course, it's all hidden nicely under USE=gtk2 and USE=gtk3, so just
> *maybe* if you have the time to read local flag descriptions for every
> single package you may notice which of the flags should be enabled to
> get a working app.
>
> But yes, wasting people's time and offering easy way to data loss is
> better than not supporting some imaginary corner case when you can
> actually use some fancy combination of applications that can actually
> run without that one library without losing stability and benefit you.
>
> I hope you are ready to pay the developers who will waste their time
> figuring out what goes wrong when you report a bug, until they figure
> out it's because you have forced GTK+ version which upstream thought
> they're supporting but they do not. That's certainly a better
> alternative than paying for hardware that can handle loading two
> libraries.

As Rich has mentioned already, if upstream thinks they support gtk2 but
it crashes when using gtk2, I am perfectly fine with the maintainer
closing the bug as WONTFIX because upstream broke things.

Alec

[Duncan]

hasufell posted on Thu, 10 Sep 2015 17:35:53 +0200 as excerpted:

>> Again, I'm saying that maintainers should be free to support multiple
>> versions if they wish to do so. They should not be required to do so.
>> And yes, I do realize that this limits options for users, but they're
>> welcome to proxy-maintain packages that do support the versions they
>> wish to use. If they want to fork upstream they're even welcome to do
>> that, but obviously that isn't going to happen often.
>>
>> I just don't think we should be in the business of saying "no" here.
>
> Again, your proposed use case is 1) imaginary 2) currently impossible to
> support, because there are lots of applications which either force gtk3
> in the ebuild or have only gtk3 supported upstream. It will be pretty
> much impossible to not have gtk3 installed or loaded into RAM, unless
> you don't use a DE in the first place and stick to terminals.

Pretty much impossible? For a kde and gtk2-based software user? Not so
much. I've only one package here using gtk3, a relatively recent
addition to a set in my world-sets file, and it's a rather optional
package (solaar, for managing my Logitech wireless devices), with a CLI-
only option, so I've been thinking about disabling gtk3 support just to
avoid having to hassle the gtk3 and supporting software updates.

One thing I learned fairly quickly with gentoo is that unlike binary
distros, over time there's a real cost to one-off or two-off
dependencies, because they aren't just single-time builds, but are
generally updated and must be repeatedly rebuilt over time. For things
you /might/ use, or do use occasionally, but only perhaps yearly or less
often, it's often more efficient to merge on-demand, then unmerge again,
until they happen to be needed again, than it is to keep them and
dependencies current the whole time. (Tho obviously, this applies more
to ~arch users who do --deep updates, than others.)

In that context, given the current usage of gtk3 in-tree, it's quite
realistic for a user to wish to avoid gtk3, if they've a number of gtk2-
only apps (as I do). Similarly the other way of course, for those with a
number of gtk3 apps, they may wish to avoid gtk2 and gtk2-only apps, if
they can, to avoid it being on their system, tho AFAIK with both chromium
and firefox being gtk2 at this point, that's a bit more difficult.

Unfortunately, gentoo/gtk's attitude makes this much more difficult than
it should be.

[hasufell]

On 09/10/2015 05:41 PM, Alec Warner wrote:
>
> There are lots of topics where I concede that QA has a point and can
> utilize its influence; but 'consistency and usability' are not topics I
> would normally expect them to impose on developers.
>

I am pretty sure tree consistency was the reason QA was founded.

[hasufell]

On 09/10/2015 04:31 PM, Vadim A. Misbakh-Soloviov wrote:
> WE HAVE NO RIGHT TO DICTATE users what they should use and what they should
> not.

You should really either reconsider your understanding of opensource or
start to pay me.

Gentoo is for the most part GPL-2 and you can fork, change and
redistribute it any way you want. We are not dictating anything.

Given the fact that we are short on manpower and that most part of the
linux ecosystem is moving towards gtk3... there has been no good
argument to support a toolkit version - that is (about to be) deprecated
- for exotic corner use cases that people tried to come up with in the
heat of the argument.

Gtk3 is not gnome3. Gtk3 is not systemd. Can we please be realistic now?

[Rich Freeman]

On Thu, Sep 10, 2015 at 12:57 PM, hasufell <hasu...@gentoo.org> wrote:
> On 09/10/2015 04:31 PM, Vadim A. Misbakh-Soloviov wrote:
>> WE HAVE NO RIGHT TO DICTATE users what they should use and what they should
>> not.
>
> You should really either reconsider your understanding of opensource or
> start to pay me.
>
> Gentoo is for the most part GPL-2 and you can fork, change and
> redistribute it any way you want. We are not dictating anything.

++

>
> Given the fact that we are short on manpower and that most part of the
> linux ecosystem is moving towards gtk3... there has been no good
> argument to support a toolkit version - that is (about to be) deprecated
> - for exotic corner use cases that people tried to come up with in the
> heat of the argument.
>

So, my issue is really with the proposition that we need a "good
argument" to support a toolkit version in the first place.

If the Firefox maintainers want to support two toolkit versions, more
power to them.

Gentoo is volunteer-based, and not a zero-sum game. If you tell
somebody that they're not allowed to support A in the tree, that
doesn't mean that they'll have more time to support B instead. It
probably just means that they'll spend less time contributing to
Gentoo. In fact, if being prevented from supporting A makes Gentoo
less useful to them overall, they might just move to some other distro
and then not only do you lose A, but you lose C, D, and E.

That might be inefficient, but it is the result of depending on free
labor. That's why we can have 400 unique window managers for X11 but
only one guy working in his spare time on openssl. People work on the
stuff that interests them, not necessarily on what is most needed by
the general public.

The Firefox maintainers don't have to have a good reason to support
two versions of gtk. As long as it generally builds/runs and complies
with security policy then they're allowed to do that, and our users
are better off for it.

You could look at any USE flag in the distro and make a case for how
we could probably get by without it. After all, most distros don't
have USE flags at all and they seem to get by.

If somebody wants to go invent x32 in their spare time and maintain it
on Gentoo, more power to them, even if only 3 people use it. I think
stuff like this is where Gentoo actually contributes the most to the
FOSS ecosystem. We're a breeding ground for crazy but innovative
ideas and the best ones can get stolen by everybody else. And just
like openssl nobody gives us much credit for it, but that's not why we
do it.

--
Rich

[Duncan]

hasufell posted on Thu, 10 Sep 2015 18:57:43 +0200 as excerpted:

> On 09/10/2015 04:31 PM, Vadim A. Misbakh-Soloviov wrote:
>> WE HAVE NO RIGHT TO DICTATE users what they should use and what they
>> should not.

@ Vadim in particular:

FWIW, some people are much more sensitive to short runs of ALL CAPS than
others. To some, ALL CAPS is ALWAYS SHOUTING, while to others (me,
apparently you/Vadim), ALL CAPS can also mean emphasis, as long as the
run isn't too long. (I do think that most would agree that whole
sentences and certainly whole paragraphs in all caps is shouting, and
just as uncomfortable to read as shouting tends to be to listen to.)

So I've learned (the hard way) to use *stars* or _underlines_ (or for
lower levels, /italics/) for emphasis, and only use ALL CAPS when I
really do intend to SHOUT, which isn't often.

Given that, many will interpret the above as a SHOUTED DEMAND, which
probably isn't what you intended, even if you (as I) feel rather strongly
about it in general.

> You should really either reconsider your understanding of opensource or
> start to pay me.

hasufell has a point here, particularly when the above is interpreted as
a SHOUTED DEMAND due to the all caps. It is said that he who codes,
makes the rules, and that really does tend to be the case. Yes, the code
is open to others to do with as they wish (including fork, etc, as
hasufell suggests), but the coder could have just done something else
instead, and it's their time they're taking, often as volunteers, to make
it available to you in the first place.

Thus, as you'll see, the argument from most supporting the choice
position is that it's the package maintainer's choice, that should the
package maintainer choose to support both toolkits, particularly in view
of upstream specifically doing the same, he should be encouraged to do so.

No demands of the maintainer, and the argument would be entirely
different, should the maintainer choose not to support both toolkits.

(Which, BTW, is why when gentoo/kde temporarily decided not to support
turning off semantic-desktop in kde4 any longer, despite upstream kde
continuing to support that choice at least thru the kde4 series, I did
actually fork the kde ebuilds, maintaining my own patches in ordered to
continue to support kde without the semantic-desktop, when gentoo/kde
would no longer do so. I even opened a discussion on the desktop list on
the topic of trying to get a user supported overlay going, similar to the
kde-sunset overlay used for kde3, when it was removed from the tree.
However, shortly after I did so, someone in the gentoo/kde project
decided they needed the no-semantic-desktop option and were thus willing
to support it in the project, so the USE flag was brought back and the
overlay discussion could be dropped. No DEMANDING continued gentoo/kde
support, despite continued upstream support, and had I DEMANDED it, I
believe it quite possible the gentoo/kde project would have voted the
other way when the one dev actually decided it /was/ worth supporting,
and we'd probably be having to do it in an overlay, today.)

But when the maintainer himself is willing to support it, no demands, as
others have argued and I agree, gentoo and the gentoo/gtk project
shouldn't stand in the way.

[hasufell]

On 09/10/2015 07:17 PM, Rich Freeman wrote:
>>
>> Given the fact that we are short on manpower and that most part of the
>> linux ecosystem is moving towards gtk3... there has been no good
>> argument to support a toolkit version - that is (about to be) deprecated
>> - for exotic corner use cases that people tried to come up with in the
>> heat of the argument.
>>
>
> So, my issue is really with the proposition that we need a "good
> argument" to support a toolkit version in the first place.
>

Because:
a) the gnome maintainers already said they are not interested in
supporting it indefinitely (they are the maintainers of gtk+ as well)
c) it introduces maintenance and configuration complexity where it is
absolutely unnecessary (because no one could come up with a real use
case) und breaks consistency

We _should_ need good arguments before we break consistency and
introduce another layer of configuration complexity, REQUIRED_USE flags
and other nastiness like package.stable.use.mask and whatnot (mgorny
already outlined a few other problems too).

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/10/2015 01:47 AM, hasufell wrote:
> On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>>
>> For me to not support gtk2 in the spacefm ebuild would be
>> providing a package inferior to upstream.
>
> That sounds like spacefm with gtk3 is lacking anything. It is not.
> Providing choice for the sake of choice is not always a good idea.
>

To my knowledge, the gtk3 version of spacefm *did* indeed have less
functionality, at first. I think they're mostly the same nowadays,
though. That said, I wasn't saying gtk3 support was lacking. But if
our package supports less things than upstreams, we're not shipping
/as complete/ a package.

For cases where either toolkit is unstable or doesn't work, I'm with
you: things that are unstable should either be clearly marked as such
or not added to the ebuild at all. But in spacefm's case, upstream
actively supports both toolkits and respects the user's choice.
Following suit here is the best idea, simply because we'd be providing
the same package and not forcing a choice on the user.

If there was something wrong with the gtk2 build -- let's say later on
gtk2 just goes unmaintained and starts breaking on Gentoo -- then
absolutely it should be removed. But for now, I think both should be
supported.

As for USE flag names, personally it doesn't really matter. I wouldn't
mind switching USE flag names, but as you said, we need consistency.
But as long as I'm maintainer of a package that gives users options
between toolkits, I will support them because as long as said toolkit
works, it's a sane choice that's *worth* supporting.

Of course, that's just my opinion and others are free to discard or
ridicule it as they see fit.

tldr: If the problem is USE flags, let's talk USE flags. If it's
supporting more than one toolkit in general, I see no reason not to
let maintainers use their discretion and not force their hand in
either direction.

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV8cimAAoJEAEkDpRQOeFw+jEQAIXcL7m+IEhDlt7pM8hQY3Bm
gTD0QzcDfXRV+wRkx35mhENXxPnT5hW/kxBYriUwfFFgKaG0BV8/Iv3P+J59J24l
R9QkgeZJ/DnWgTTYLfiY0tiRnua1g8CWTKG9mWRy1oaLKy0WOLnpcn90sBGVKk5O
qVWZditk16TiDPcbehPZQCUshnM1+INie3ANh2DeNrNJk6Lg2OmwPB5zeg8t70kn
cbnFEK1kansHVgglBoka/syY3oXrbEATL1xzLIkCCUp64V7+1yT+bwA1K79BJB9z
SVawPlI8CwaI3jGfT228gUCdyQzOdDa7ES9PHcMFuD5VettrVMdOpQ7Nm4RXIItt
LdsTGBjuZ2hu3sQRnsQcOLJQTFsWMUr7kMvBPkKwM8t/HDRJ6zfgP7ND8mi+CktE
rxa5KcbnOV3Kz13YtuS9SD7MdIjr4X/S4FTGhL23DXNGksltZ3+pRPMEHeV25a8l
opFYW55UK4Des1HK00glkLJTNsXx4Kv9/rSgh6hpATBKf66Ft9yZ7CtqJWx3EesU
QRfQ2T5PNDl2HNbybXvggQsg+oVnlPTpwRs2B5FlWHZfKxV+c5sWPtHPsxHpclw/
5W/YfUin5DnxBO8bCTk40rpeq3cTdUJkA2i2F63glCcOhXt2LGwq54uKg4GR6v38
nWi5NyH2vOwR5rhaqC5q
=oW5i
-----END PGP SIGNATURE-----

[Rich Freeman]

On Thu, Sep 10, 2015 at 2:21 PM, hasufell <hasu...@gentoo.org> wrote:

> On 09/10/2015 08:15 PM, Daniel Campbell wrote:
>>
>> tldr: If the problem is USE flags, let's talk USE flags. If it's
>> supporting more than one toolkit in general, I see no reason not to
>> let maintainers use their discretion and not force their hand in
>> either direction.
>>
>

> We have provided several arguments here repeatedly.
>

Well, right now the status quo is that this is up to maintainers.
There is no policy that states otherwise.

The USE flag issue is on the next council agenda, though I'm not
really confident that we'll resolve it in one go - there are only a
few days before the meeting. If anybody has concerns about the
approach that we take I'd suggest posting them on the thread, but I
suspect that most likely the council will go around the circle and
assess where everybody generally stands, then propose something more
solid for a vote the following meeting (which gives everybody an
opportunity to shoot holes it in beforehand).

--
Rich

[Rich Freeman]

On Thu, Sep 10, 2015 at 2:05 PM, hasufell <hasu...@gentoo.org> wrote:
> On 09/10/2015 07:17 PM, Rich Freeman wrote:
>>>
>>> Given the fact that we are short on manpower and that most part of the
>>> linux ecosystem is moving towards gtk3... there has been no good
>>> argument to support a toolkit version - that is (about to be) deprecated
>>> - for exotic corner use cases that people tried to come up with in the
>>> heat of the argument.
>>>
>>
>> So, my issue is really with the proposition that we need a "good
>> argument" to support a toolkit version in the first place.
>>
>
> Because:
> a) the gnome maintainers already said they are not interested in
> supporting it indefinitely (they are the maintainers of gtk+ as well)

I was not suggesting that anybody be forced to maintain gtk2 itself.
However, I don't see any efforts underway to remove it right now.
gtk2 isn't actually deprecated in Gentoo. If it were then I'd look at
things differently.

If the day comes when nobody wants to maintain gtk2 in the tree, then
it will have to go. If a single developer or proxy wants to maintain
it and does so, then it can stay.

And nothing in portage will be supported "indefinitely."

--
Rich

[hasufell]

On 09/10/2015 08:15 PM, Daniel Campbell wrote:
>

> To my knowledge, the gtk3 version of spacefm *did* indeed have less
> functionality, at first. I think they're mostly the same nowadays,
> though.

That's why spacefm ebuild did not switch to gtk3 when gtk3 support was
still experimental.

> That said, I wasn't saying gtk3 support was lacking. But if
> our package supports less things than upstreams, we're not shipping
> /as complete/ a package.
>

This sentiment is very confusing. Not even spacefm provides all
available configure switches as USE flags and I am glad that it does not.

>
> tldr: If the problem is USE flags, let's talk USE flags. If it's
> supporting more than one toolkit in general, I see no reason not to
> let maintainers use their discretion and not force their hand in
> either direction.
>

[Paweł Hajdan, Jr.]

On 9/10/15 8:05 PM, hasufell wrote:
> a) the gnome maintainers already said they are not interested in
> supporting it indefinitely (they are the maintainers of gtk+ as well)

Aren't there at least some gtk2-only apps? It seems to me we're not that
close to removal of gtk2 from the tree.

I'm also not aware of bugs being files about Gentoo gtk maintainers as a
result of gtk2/gtk3 USE flags on packages - please let me know if there
are in fact such bugs.

> c) it introduces maintenance and configuration complexity where it is
> absolutely unnecessary (because no one could come up with a real use
> case) und breaks consistency

Who decides whether a use case is valid? Clearly having discussions like
this for 10 years indicates people are interested in this.

I'm not saying a user is always right. I just wouldn't go out of my way
to block it if package maintainers are willing to support such requests.

Paweł

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Honestly, I can understand where the gnome team is coming from wrt
keeping things moving forward. I personally don't think highly of
gtk3, but in the grand scheme of things, if that's where it's going,
maybe we *should* establish some policy on how USE flags are named
and/or used. Use cases do indeed differ; sometimes it enables an
optional GUI, sometimes it's one of many toolkit options. Whatever
decision is made I'm fine with so long as I can ensure users of
packages I maintain can choose which toolkit the package is built with
(assuming upstream supports it, of course).

I like the general 'gtk' flag we generally use to choose *which*
toolkit, and local USE flags for specific versions, if they are
supported. But in that case, the general gtk flag should be
interpreted as the latest version supported, so users don't come
across weirdly behaving packages that default to gtk2 (unless that
version is the most stable).

It's hard to apply such standards across a tree of thousands of
packages, each with their own upstreams, build systems, code
standards, and so on. I'm sure there's something we can find that
enables us to continue providing choice to users while maintaining
some semblance of consistency across the tree.

For starters, versioned USE flags more than likely don't belong in
make.conf's USE variable and shouldn't be global.

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV8pjLAAoJEAEkDpRQOeFwu04P/0Hypny+iEXfEnvzl5MAVb+y
OdpUYwhuhDq79cK5DEbs0sfc9deTYWj8PL8FOpxrSnunT6hwwesMepXQDWFInRhE
aF9tvTgZJG7NlW6D4vG6d2+sOluuYXqkv75vezf173k/02WD8FxVlD3dbeIOrItn
IH7JiBfJNzyXLgF9bjzxxV5ANe37jWf8j5ZGfvlv/NEiasM8zsDJzC0MQeEnPy6/
RNgjvP9U+BtWxHwLjgib6F4aYIr5aZzwa7bgbP7JGN88RPgui53LgklZjsxLh1sG
qXnFmInejE2gNPt2yO5yxahue2tABCKiSFiZcYyhDMyA3vW+c4Uu71szlB2iWsWG
ZeDG1FY5SR4nreD/Er/q5GQPuU/B32FzuJpc+e7F5uzBGVY+ZuHX9UJnFb6KFwg/
hxDXiVwJLoMHEMIfqk6NRI0A44aLDqJamND9Hv3D97jC1kLnu56qzhMVj+8/SQkn
bXPtBQJEybMIemmobtm7clnjtY2wbFo4paN269+gJkgHoKmA+FpCCDX2eBFvCl/G
yNkFEFwXp0SN4XaUQ3LysBlh3BZcb1grUeJKxt5punf9T6/Cc16V5jzjD7e2o/3g
rD/oL5ea/BEyB2QPFII7IJl8V9kjAnVSPtGhvn8UJNtLUbS3tZEtwXONwDLNQV0R
AD8GxhNJBRgau84x55na
=v5ss
-----END PGP SIGNATURE-----

[Rich Freeman]

On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell <z...@gentoo.org> wrote:
>
> I like the general 'gtk' flag we generally use to choose *which*
> toolkit, and local USE flags for specific versions, if they are
> supported. But in that case, the general gtk flag should be
> interpreted as the latest version supported, so users don't come
> across weirdly behaving packages that default to gtk2 (unless that
> version is the most stable).
>

>...

>
> For starters, versioned USE flags more than likely don't belong in
> make.conf's USE variable and shouldn't be global.
>

That was roughly my proposal.

USE=gui or something like that if the main effect is to have a gui or
not. That is the sort of thing that SHOULD go in make.conf or in a
profile. If disabling gtk makes it a console-only application then
use the gui flag.

USE=gtk if the main effect is to select /which/ toolkit is used if
more than one is optionally supported. That /might/ go in a make.conf
or profile, but probably shouldn't in general. It is more appropriate
for something like the desktop/gnome profile than the desktop profile.

USE=gtk# if you're picking which version to use. That should /almost
never/ go in a profile (unless you're talking about a testing profile
of some kind, such as on an overlay), or in a global config unless you
REALLY know what you're getting into. Users setting this globally
should expect to run into bugs. The package should default these
flags to whatever is most appropriate for the specific package.

I'd be tempted to even say to not have gtk3 but instead call the flag
chromium-gtk3 or whatever so that it becomes very difficult to put in
the global config. However, that goes against our general principle
of letting the user break their system and keep the pieces if they
think they know what they're doing. If somebody WANTS to test out a
gtk3-only system or whatever they should have the freedom to do so,
understanding that testing sometimes uncovers problems.

Of course any change will need a transition period, news, handbook
updates, etc. For the person who wants the "just works" experience
they can pick a profile and it will do the right thing, and if they
want to tailor things a bit more the USE=(-)gui flag will do what it
would be expected to do.

--
Rich

[Duncan]

Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as excerpted:

> USE=gui or something like that if the main effect is to have a gui or
> not.
> That is the sort of thing that SHOULD go in make.conf or in a profile.
> If disabling gtk makes it a console-only application then use the gui
> flag.

I like the general proposal, but since it's going to council, can we try
to kill another bird with the same stone? This USE=gui helps...

Wayland's coming, and to the extent that USE=X has previously indicated a
GUI, much like USE=gtk and USE=qt indicating the same thing, we're going
to have problems.

Can we make USE=gui the generic policy for that, and deprecate more
specific forms for choosing /any/ gui, so they can be used for choosing
/which/ gui?

Then of course ordain both X and wayland USE flags for choosing specific
gui platform, like gtk and qt did at their level traditionally.

The question then remains whether ncurses, etc, should be treated as a
gui. Maybe make mention of that one way or the other in the policy as
well.

[Rich Freeman]

On Fri, Sep 11, 2015 at 1:11 PM, Duncan <1i5t5....@cox.net> wrote:
> Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as excerpted:
>
>> USE=gui or something like that if the main effect is to have a gui or
>> not.
>> That is the sort of thing that SHOULD go in make.conf or in a profile.
>> If disabling gtk makes it a console-only application then use the gui
>> flag.
>
> I like the general proposal, but since it's going to council, can we try
> to kill another bird with the same stone? This USE=gui helps...
>
> Wayland's coming, and to the extent that USE=X has previously indicated a
> GUI, much like USE=gtk and USE=qt indicating the same thing, we're going
> to have problems.
>
> Can we make USE=gui the generic policy for that, and deprecate more
> specific forms for choosing /any/ gui, so they can be used for choosing
> /which/ gui?

That was exactly why I used "gui" and not "X". We're going to run
into the exact same problem once Wayland comes along with the way
things have been done so far.

>
> The question then remains whether ncurses, etc, should be treated as a
> gui. Maybe make mention of that one way or the other in the policy as
> well.
>

I actually was pondering that and left it out of my email. My gut
feeling is that ncurses should be left alone for now. USE=-gui would
mean console-only, whether that happens to include support for
ncurses, aa, or whatever.

Are there any applications out there which behave dramatically
differently if they do/don't have ncurses support built-in? If you
set TERM=dumb I imagine that software which actually supports this
would just behave accordingly (ie if it is just using colors or moving
progress bars or whatever it will drop the decorations). Usually
though dumb terminal software tends to be somewhat dedicated (for
things like editors and the like).

I don't want to complicate things if nobody really cares about them.
However, in theory you could treat various console-enhancing libraries
in the same way. There is also svgalib and the like.

--
Rich

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/09/15 01:41 PM, Rich Freeman wrote:
> On Fri, Sep 11, 2015 at 1:11 PM, Duncan <1i5t5....@cox.net>
> wrote:
>> Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as
>> excerpted:
>>
>>> USE=gui or something like that if the main effect is to have
>>> a gui or not. That is the sort of thing that SHOULD go in
>>> make.conf or in a profile. If disabling gtk makes it a
>>> console-only application then use the gui flag.
>>
>> I like the general proposal, but since it's going to council,
>> can we try to kill another bird with the same stone? This
>> USE=gui helps...
>>
>> Wayland's coming, and to the extent that USE=X has previously
>> indicated a GUI, much like USE=gtk and USE=qt indicating the
>> same thing, we're going to have problems.
>>
>> Can we make USE=gui the generic policy for that, and deprecate
>> more specific forms for choosing /any/ gui, so they can be used
>> for choosing /which/ gui?
>
> That was exactly why I used "gui" and not "X". We're going to
> run into the exact same problem once Wayland comes along with the
> way things have been done so far.
>

So, IUSE="X" has generally been used for gui, but more technically
it's used to depend on and build against x11-libs/* packages. The
fact that this gives a GUI is practically a side-effect. When
wayland comes along, do these packages still build against
x11-libs/* to support wayland?

I'm just wondering if we're jumping the gun a little bit on
IUSE="gui".. yes it'll be nice to have one flag that "just works"
for anyone not caring about the details, but it'll also mean
propagating a slew of REQUIRED_USE=" {X,wayland,gtk,qt4,qt5}? ( gui
)" entries and a lot of extra use-defaults which may or may not
cleanup the sub-profiles of desktop/ ....

Also, I believe we need to have the conversation about the pros and
cons of IUSE=gui here before the council meeting, yes?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXzF48ACgkQAJxUfCtlWe0ZQwD8CPt1rOkynOgb/as1gH/u2iYY
Du/EFPwleMDHVgMJDFYBAOfjguA8D1xTPJU9vzsvBf+y4rVFVvvFHuIX8+yyadjD
=SnN3
-----END PGP SIGNATURE-----

[Rich Freeman]

On Fri, Sep 11, 2015 at 2:03 PM, Ian Stakenvicius <a...@gentoo.org> wrote:
> I'm just wondering if we're jumping the gun a little bit on
> IUSE="gui".. yes it'll be nice to have one flag that "just works"
> for anyone not caring about the details, but it'll also mean
> propagating a slew of REQUIRED_USE=" {X,wayland,gtk,qt4,qt5}? ( gui
> )" entries and a lot of extra use-defaults which may or may not
> cleanup the sub-profiles of desktop/ ....

A completely valid concern. Of course, there is no requirement that
all this stuff happen overnight.

> Also, I believe we need to have the conversation about the pros and
> cons of IUSE=gui here before the council meeting, yes?

You can read my original post to -project:
http://article.gmane.org/gmane.linux.gentoo.project/4776

I did start it out with my reservation that this probably wouldn't
come to a vote. However, I did want to at least toss out a specific
proposal so that we have something to throw darts at, vs just going
around the room saying "sounds like something that might need some
attention."

This is of course an opportunity to have that conversation, but I
recognize that we're starting pretty late considering the timing of
the meeting. I didn't really intend to actually push for a vote on
this.

Most likely we'll express thoughts both pro and con, and then take it
back to the lists and maybe try to finalize something next month.

My sense is that this has been going on for a long time though and
we're seeing problems over and over. I agree that wayland is still a
bit off in the future, but I can see it coming up again there. In the
meantime both qt and gtk have run into this. I don't want to do
something just to do something, but it seems like my proposal is along
the lines of what most have been talking about.

--
Rich

[hasufell]

On 09/11/2015 08:03 PM, Ian Stakenvicius wrote:
>
> So, IUSE="X" has generally been used for gui, but more technically
> it's used to depend on and build against x11-libs/* packages. The
> fact that this gives a GUI is practically a side-effect. When
> wayland comes along, do these packages still build against
> x11-libs/* to support wayland?
>
> I'm just wondering if we're jumping the gun a little bit on
> IUSE="gui".. yes it'll be nice to have one flag that "just works"
> for anyone not caring about the details, but it'll also mean
> propagating a slew of REQUIRED_USE=" {X,wayland,gtk,qt4,qt5}? ( gui
> )" entries and a lot of extra use-defaults which may or may not
> cleanup the sub-profiles of desktop/ ....
>
> Also, I believe we need to have the conversation about the pros and
> cons of IUSE=gui here before the council meeting, yes?
>

I already use IUSE=gui and will keep doing that.

USE flags in gentoo are the best and the worst thing at the same time.
They are also mostly the main reason people don't like gentoo, because
USE flags are (for todays situation) pretty much not an appropriate
pattern to reflect real-world configuration. To be more precise... USE
flags are first-class citizens and there is only one layer of them.
There's not configuration pattern/abstraction behind them. If you wonder
what I am talking about, have a look at NixOS. The reason we lack proper
declarative configuration is also the reason we had to introduce this
ugliness called REQUIRED_USE. Instead of saying "gui.gtk" we say
"REQUIRED_USE="gui? ( || ( gtk ... ) )". And it will get worse. I
wonder when people start realizing that.

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

So are you suggesting maybe we come up with namespaced USE flags? That
would be interesting.

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV82lLAAoJEAEkDpRQOeFwiUAQAMoAzkd1NKwDaMeiKSwD1pIa
0RhytZ+YFMQp+A+eLuIIG7yzpbomzwMuQGe1YqHEAHibZx/C/Dfjdx5MMyAGAnkk
Am+ysOoHOZdGn/F5AMWNko4HZ+QxD22a1z6Mbkf00PE5J53vzgCAPh7nX6wRYFUP
Ag54pWCXP8xAN6hMmHtcyxz3vZ2s4AZfTvAlLcwVSCJmUa4Ki+64T/L8I6UMUC2h
qabu46RePWYDaTBDw7HB29Yja/UggGC7S9kTIvJYCwfyCbENOIa6kOU/qKeUP+Im
6blr8WfdWMUVlYxKlbPaibPQKUw3KCQIylLlp6Jn8Ix8tePyxm+086AE7q4qhbQX
64d6zbB+TaK8JC+ujWf90DmlXU0nTyMZ34Cooil1PwD5/b70lcSmTjxmffqSRG0w
KjUlI7op63qtiJ1r2PyLx1PliC6DVvhV9cZqO7oSB+mNi3oPKFCBNvIyhiCMQxzL
PrT80pF9HxloOarIMy0BCoHcr+qYYaoB20WqNC4XfM19iWsXQkvFCyUBFb9VxZd0
+EcGRRoVwr1UZjO8zYx5l1gdsvtck1Ka4WZgqVqeHFOgR+HJ18s5IfDLdSjOcDn4
F+XAewblzRAGsF4zM59q7ZIb70mmJmcAN6c1EmZwdrh0OAMH+HhXB97Z5tI/e3xY
8ouxCkDbfXutEydYI7mP
=jIAs
-----END PGP SIGNATURE-----

[Duncan]

hasufell posted on Fri, 11 Sep 2015 22:34:04 +0200 as excerpted:

> USE flags in gentoo are the best and the worst thing at the same time.
> They are also mostly the main reason people don't like gentoo, because
> USE flags are (for todays situation) pretty much not an appropriate
> pattern to reflect real-world configuration. To be more precise... USE
> flags are first-class citizens and there is only one layer of them.

I agree with the one-layer problem, but just to say, without something
like USE flags, despite their single-layer-problem, I'd not be using
gentoo. Perhaps better can be done, but in the absence of better at the
moment, for better or worse, USE flags do get the job done, and I'd hate
to be without either them or an at least equally (if not more) powerful
replacement.

[Duncan]

Ian Stakenvicius posted on Fri, 11 Sep 2015 14:03:59 -0400 as excerpted:

> Also, I believe we need to have the conversation about the pros and cons
> of IUSE=gui here before the council meeting, yes?

Well, I brought up the idea in the context of Rich's already stated plan
to start the discussion this council meeting, but only to take a straw-
poll vote to get a general idea where council members stand, this time,
and to hash it out more fully on the list, possibly with the benefit of
an initial council suggested wording, before the real vote, presumably at
the /next/ (that is, second from now) meeting.

So that would be a yes, but I considered that presupposed. =:^)

[Dale]

Duncan wrote:
> hasufell posted on Fri, 11 Sep 2015 22:34:04 +0200 as excerpted:
>
>> USE flags in gentoo are the best and the worst thing at the same time.
>> They are also mostly the main reason people don't like gentoo, because
>> USE flags are (for todays situation) pretty much not an appropriate
>> pattern to reflect real-world configuration. To be more precise... USE
>> flags are first-class citizens and there is only one layer of them.
> I agree with the one-layer problem, but just to say, without something
> like USE flags, despite their single-layer-problem, I'd not be using
> gentoo. Perhaps better can be done, but in the absence of better at the
> moment, for better or worse, USE flags do get the job done, and I'd hate
> to be without either them or an at least equally (if not more) powerful
> replacement.
>

+1

If there is not some way to disable/enable things, there is little point
is using Gentoo. Actually, Gentoo loses something huge that makes
Gentoo different. Besides, how would you tell a package how and what to
compile without USE flags??

Dale

:-) :-)

[Raymond Jennings]

On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman <ri...@gentoo.org> wrote:

On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell <z...@gentoo.org> wrote:
>
> I like the general 'gtk' flag we generally use to choose *which*
> toolkit, and local USE flags for specific versions, if they are
> supported. But in that case, the general gtk flag should be
> interpreted as the latest version supported, so users don't come
> across weirdly behaving packages that default to gtk2 (unless that
> version is the most stable).
>
>...
>
> For starters, versioned USE flags more than likely don't belong in
> make.conf's USE variable and shouldn't be global.

Personally i disagree with this.

Versioned use flags for widely used dependencies (like a windowing toolkit) IMO qualify as global USE flags because they have a common effect across many packages.

That was roughly my proposal.

USE=gui or something like that if the main effect is to have a gui or
not.  That is the sort of thing that SHOULD go in make.conf or in a
profile.  If disabling gtk makes it a console-only application then
use the gui flag.

USE=gtk if the main effect is to select /which/ toolkit is used if
more than one is optionally supported.  That /might/ go in a make.conf
or profile, but probably shouldn't in general.  It is more appropriate
for something like the desktop/gnome profile than the desktop profile.

USE=gtk# if you're picking which version to use.  That should /almost
never/ go in a profile (unless you're talking about a testing profile
of some kind, such as on an overlay), or in a global config unless you
REALLY know what you're getting into.  Users setting this globally
should expect to run into bugs.  The package should default these
flags to whatever is most appropriate for the specific package.

I really like this approach, and I think that having tiers of (gui)->(qt/gtk)->(qt4/qt5//gtk2/gtk3) would go a long way to keeping USE flags coherent.

I'd be tempted to even say to not have gtk3 but instead call the flag
chromium-gtk3 or whatever so that it becomes very difficult to put in
the global config.  However, that goes against our general principle
of letting the user break their system and keep the pieces if they
think they know what they're doing.  If somebody WANTS to test out a
gtk3-only system or whatever they should have the freedom to do so,
understanding that testing sometimes uncovers problems.

I actually also think that there should be a single USE flag for building on gtk3, called gtk3.  calling it "(packagename)-gtk3" is a bit redundant, and also flies in the face of having a single global flag with a coherent purpose.

[Duncan]

Raymond Jennings posted on Fri, 11 Sep 2015 21:55:46 -0700 as excerpted:

> On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman <ri...@gentoo.org> wrote:
>
>> USE=gui or something like that if the main effect is to have a gui or
>> not. That is the sort of thing that SHOULD go in make.conf or in a
>> profile. If disabling gtk makes it a console-only application then use
>> the gui flag.
>>
>> USE=gtk if the main effect is to select /which/ toolkit is used if more
>> than one is optionally supported. That /might/ go in a make.conf or
>> profile, but probably shouldn't in general. It is more appropriate for
>> something like the desktop/gnome profile than the desktop profile.
>>
>> USE=gtk# if you're picking which version to use. That should /almost
>> never/ go in a profile (unless you're talking about a testing profile
>> of some kind, such as on an overlay), or in a global config unless you
>> REALLY know what you're getting into. Users setting this globally
>> should expect to run into bugs. The package should default these flags
>> to whatever is most appropriate for the specific package.
>>
> I really like this approach, and I think that having tiers of
> (gui)->(qt/gtk)->(qt4/qt5//gtk2/gtk3) would go a long way to keeping USE
> flags coherent.

The other possibility, which I haven't seen raised but if we're going to
examine the options I think we at least need this on record as having
been discussed, is...

Just bite the bullet and create entire USE flag families such that an
ebuild can choose the flag appropriate to how it actually uses it. AFAIK
this would need EAPI help, for reasons given below, but it should be
doable.

gui
gui-gtk
gui-gtk-2
gui-gtk-3
gui-qt
gui-qt-4
gui-qt-5

(Do we want X and wayland variants of the above?)

req-alt-gtk
req-alt-gtk-2
req-alt-gtk-3
req-alt-qt
req-alt-qt-4
req-alt-qt-5

choice-alt-gtk
choice-alt-gtk-2
choice-alt-gtk-3
choice-alt-qt
choice-alt-qt-4
choice-alt-qt-5

...

Then people could set in make.conf something like...

USE="gui -gui-qt-5"

... which would mean "I normally want GUI features built, but not if it
means pulling in qt5."

For the req-alt (required alternative) flags, the user could set ONLY ONE
at a specific choice-level (here, the gtk/qt choice level, and the gtk2/3
and qt4/5 choice-levels), with EAPI enforcing it.

Then an ebuild would set the /deepest/ level it needed, and possibly a
choice variable, something like (UH=USE-Hierarchy)...

UH_MAX_LVL="gui-gtk-2,gui-gtk3 level-use-x,level-use-y"
UH_CHOICE=""

... and the EAPI, possibly plus an eclass to allow expanding the sets,
would then have logic similar to the following table for the gtk set
(EAPI support needed as traditional USE flags default off if not set on,
and three-way flags, on/off/unset, would be necessary here):

! = unset
- = set -flag
+ = set flag (+flag)
x = flag setting doesn't matter

gui gui-gtk gui-gtk-2 gui-gtk-3 note/build
----------------------------------------------------------------
! ! ! ! all unset, build none
! ! ! - unset/negative, build none
! ! ! + only gtk3 set, build gtk3
! ! - ! unset/negative, build none
! ! - - unset/negative, build none
! ! - + build gtk3
! ! + ! build gtk2
! ! + - build gtk2
! ! + + build both gtk2/3 [1]

! - x x -gui-gtk, build none [2]

! + ! ! ebuild-pref [3]
! + ! - build gtk2
! + ! + build gtk3
! + - ! build gtk3
! + - - build none [4]
! + - + build gtk3

- x x x -gui, build none [2]

+ ! ! ! +gui, !others, eb-pref [3]

+ - x x -gui-gtk, build none [5]

+ + ! ! ebuild-pref [3]
+ + ! - build gtk2
+ + ! + build gtk3
+ + - ! build gtk3
+ + - - build none [4]
+ + - + build gtk3
+ + + ! build gtk2
+ + + - build gtk2
+ + + + build both gtk2/3
--------------------------------------------------------------

[1] Since UH_CHOICE was unset or null in the ebuild, both can be built.
If it was set, the user/profile settings for choice-alt-gtk* would be
evaluated to decide.

[2] With the higher level flag set negative, the lower level flags don't
matter as the user/profile said they don't want it with the higher level
flag.

[3] With the higher level set positive and lower levels unset, user/
profile doesn't care at the lower level, so build both or maintainer
pref, if ebuild didn't set UH_CHOICE. If ebuild set UH_CHOICE, only one
can be built, evaluate the user/profile value for choice-alt-gtk* to
decide.

[4] User/profile says they want gtk GUI, but don't want either gtk2 or
gtk3. What? But the effect is gui-gtk but not if it's either of the
possible gtk options, so don't build them.

[5] User/profile says gui, but not when it's gtk, so gtk builds being the
only gui possible, don't build them.


Obviously if qt4/5 are also options, there'd be a similar matrix for
them, plus another level controlling the qt/gtk choice.

Fed the correct UH_* settings and deciding based on the user/profile
settings, the EAPI or eclass function would return a list of options to
build from among those indicated by the UH_* vars, with the added
possibility of ebuild-preference, which would let the ebuild choose its
preferred, or it could build both/all.

At the gtk-only or qt-only levels, there'd be only the version choices.
Similarly if only one version of each was supported, as it'd then be a qt/
gtk choice. But if gtk2/3 and qt4/5 are all supported, there'd have to
be a way to return "ebuild-choice of gtk, not qt, please", or conversely,
"ebuild choice of qt, not gtk, please", as well as "ebuild-choice of
whatever". To complete the set, "ebuild choice of gtk/qt, but if it's
gtk, I want this version" (and similar for qt) might be worthwhile, but
I'm not sure whether there'd be a real use-case for that or not. If not,
perhaps it could simply spit an error, to avoid having to implement that
bit of the choice matrix.


Clearly this would be rather complex to setup, but the idea would be to
code it once in the EAPI possibly plus the eclass, after which ebuilds
would simply set the vars according to what choices they had, call the
function to return the build choice, and let the return tell them what to
build. Thus, it would be once per PM, plus possibly the expansion in the
eclass, with little code in the ebuilds themselves. So complex, yes, but
if it can solve the problem so we don't keep coming back to it...

Like I said, I'm not sure it's practical, but even if not, I believe
there's value in simply having it on the table for discussion, if for
nothing else than for actually going there, as an example of the
potential complexity of trying to take it too far.

[Rich Freeman]

On Sat, Sep 12, 2015 at 12:55 AM, Raymond Jennings <shen...@gmail.com> wrote:
> On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman <ri...@gentoo.org> wrote:
>>
>> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell <z...@gentoo.org> wrote:
>> >
>> > I like the general 'gtk' flag we generally use to choose *which*
>> > toolkit, and local USE flags for specific versions, if they are
>> > supported. But in that case, the general gtk flag should be
>> > interpreted as the latest version supported, so users don't come
>> > across weirdly behaving packages that default to gtk2 (unless that
>> > version is the most stable).
>> >
>> >...
>> >
>> > For starters, versioned USE flags more than likely don't belong in
>> > make.conf's USE variable and shouldn't be global.
>
> Personally i disagree with this.
>
> Versioned use flags for widely used dependencies (like a windowing toolkit)
> IMO qualify as global USE flags because they have a common effect across
> many packages.

He wasn't suggesting that they have different meanings for different
packages. By saying that they shouldn't be global he meant that users
should not typically be manipulating them at a global level, such as
in make.conf.

Back in the day it was common to stick flags like these in make.conf
or in profiles, since if you didn't packages wouldn't build GUIs and
such. That was before USE defaults and it caused a lot of headaches
when multiple versions of toolkits started coming along and setting
these flags started causing harm.

But, the way we use the terms local/global USE flags is confusing.
They can mean that a flag has a package-specific vs global meaning, or
the terms can mean that it is recommended that the flag be enabled at
the package.use level vs at the make.conf level. To be fair to you,
until very recently the first meaning was the most common. People are
talking more about the second meaning of late because of problems that
happen when people try to tweak fairly detailed settings like gtk3 at
the global level.

>
>> I'd be tempted to even say to not have gtk3 but instead call the flag
>> chromium-gtk3 or whatever so that it becomes very difficult to put in
>> the global config. However, that goes against our general principle
>> of letting the user break their system and keep the pieces if they
>> think they know what they're doing. If somebody WANTS to test out a
>> gtk3-only system or whatever they should have the freedom to do so,
>> understanding that testing sometimes uncovers problems.
>
> I actually also think that there should be a single USE flag for building on
> gtk3, called gtk3. calling it "(packagename)-gtk3" is a bit redundant, and
> also flies in the face of having a single global flag with a coherent
> purpose.
>

The only reason for doing it the other way would be to make it harder
for users to shoot themselves in the foot by setting these flags in
make.conf. They'd have to put 50 flags in make.conf and not just one.
However, in general Gentoo operates under the principle that while we
should avoid surprising the user, we shouldn't actually make it hard
for the user to override our decisions when they feel it is best.

--
Rich

[Rich Freeman]

On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5....@cox.net> wrote:
>
> Just bite the bullet and create entire USE flag families such that an
> ebuild can choose the flag appropriate to how it actually uses it. AFAIK
> this would need EAPI help, for reasons given below, but it should be
> doable.
>
> gui
> gui-gtk
> gui-gtk-2
> gui-gtk-3
> gui-qt
> gui-qt-4
> gui-qt-5

I'm going to have to read the rest of your email about 14 times to
fully grok it, but one thing that strikes me about this approach, and
perhaps mine as well, is that this assumes that USE=-gui should imply
USE="-gtk -qt" or similar.

What if qt or gtk is used for more than just the GUI. What if the
console version of the program still uses other functions in these
toolkits besides window decoration/etc?

Granted, I suspect that in such a case turning off any of this stuff
is probably not build-time-configurable. If you want the console-only
version you'd just pass the appropriate command line option (like
deluge's --ui option).

However, it is conceivable that you could design a build system so
that the GUI requires qt and libfoo, spell check requires qt only, and
you could build the program with GUI support, spell check support, or
neither. If you built with USE="-gui spellcheck" then you'd want qt
enabled but libfoo disabled. That is obviously a highly contrived
example and perhaps we don't need to worry about this scenario.
However, it does illustrate the general danger of making USE flags a
strict hierarchy. A hierarchy like qt/qt4 is probably fairly safe,
but when you generalize to gui/qt/qt4 you're making the assumption
that qt is only used for guis.

But I do like the concept, well, conceptually.

--
Rich

[hasufell]

On 09/12/2015 01:52 AM, Daniel Campbell wrote:
> On 09/11/2015 01:34 PM, hasufell wrote:
>> I already use IUSE=gui and will keep doing that.
>
>> USE flags in gentoo are the best and the worst thing at the same
>> time. They are also mostly the main reason people don't like
>> gentoo, because USE flags are (for todays situation) pretty much
>> not an appropriate pattern to reflect real-world configuration. To
>> be more precise... USE flags are first-class citizens and there is
>> only one layer of them. There's not configuration
>> pattern/abstraction behind them. If you wonder what I am talking
>> about, have a look at NixOS. The reason we lack proper declarative
>> configuration is also the reason we had to introduce this ugliness
>> called REQUIRED_USE. Instead of saying "gui.gtk" we say
>> "REQUIRED_USE="gui? ( || ( gtk ... ) )". And it will get worse. I
>> wonder when people start realizing that.
>
>
> So are you suggesting maybe we come up with namespaced USE flags? That
> would be interesting.
>

I'm not sure we can do that without breaking gentoo. At least, it would
be a _huge_ EAPI change.

It would require a lot of PM work, would break our configuration format
(if you want to do it properly) and probably have other side effects for
running systems.

And if you have followed NixOS development... you know that you can
screw this up as well, because consistency is even more important if you
really want declarative configuration. And I'm not sure there is enough
interest in consistency in gentoo. People seem to be fine with micro
managing USE flags in order to achieve a particular configuration state
which can break arbitrarily on any update.

[Duncan]

Rich Freeman posted on Sat, 12 Sep 2015 06:48:13 -0400 as excerpted:

> On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5....@cox.net> wrote:
>>
>> Just bite the bullet and create entire USE flag families such that an
>> ebuild can choose the flag appropriate to how it actually uses it.
>> AFAIK this would need EAPI help, for reasons given below, but it should
>> be doable.
>>
>> gui
>> gui-gtk
>> gui-gtk-2
>> gui-gtk-3
>> gui-qt
>> gui-qt-4
>> gui-qt-5
>
> I'm going to have to read the rest of your email about 14 times to fully
> grok it,

LOL. I started with a paragraph describing each setting, and very
quickly decided /that/ wasn't going to work! I was "in a maze of twisty
passages, all different!"[1] So I tried the matrix/table. That was bad
enough, but at least with the table, I could cover all possibilities
systematically without losing track of where I was.

Luckily, the logic can be written once and used by many. Additionally,
once setup, ordinary ebuild maintainers won't have to worry about the
logic matrix, they'll simply setup the vars describing the candidates,
call the function, get a result, and act on it. To ordinary ebuild
maintainers it can be as effectively black-box as a call to any EAPI/PM
supplied function is, today.

> but one thing that strikes me about this approach, and perhaps
> mine as well, is that this assumes that USE=-gui should imply USE="-gtk
> -qt" or similar.
>
> What if qt or gtk is used for more than just the GUI. What if the
> console version of the program still uses other functions in these
> toolkits besides window decoration/etc?

You're expanding my realm of possibilities here, thanks! =:^)

Good point, particularly since qt5 is modularized with the specific
intent of making it useful for CLI-only as well. Except that no, the
proposal does /not/ necessarily assume USE=-gui means USE=-qt and -gtk as
well. While my example had nothing suggesting CLI, keep in mind that
these are effectively hierarchy flags, with gui-* used as the example.

This was a (possibly abridged, there's other GUI toolkits...) example of
the use and logic of the gui-* flags, but use of other flags and flag-
families in the same ebuild would certainly be possible. Presumably one
such flag (and perhaps eventually flag-family, if called for) could be
cli-qt-5.

Meanwhile, keep in mind that as described, the ebuild would set the
candidates, then call a function which would return the selected
candidates to build. But that doesn't prevent the ebuild from using
further logic with other flags, etc.

So taking your example, the ebuild would do the whole gui-* flag family
thing as I described, get the results for that, and could then either do
another family setup and get more results, or could throw in more
conventional flags. And one such flag, possibly individual at first,
wold be cli-qt-5, controlling this option separately. If later there
were enough such flags to make a cli-* family, existing ebuilds using cli-
qt-5 would continue to use that individual flag, while revision-bumps or
new versions could start using the cli-* family, setting it up using UH-*
variables and calling the function again, getting a CLI result which
could be used, just as they got a GUI result to use.

---
[1] https://en.wikipedia.org/wiki/Colossal_Cave_Adventure