[gentoo-dev] gtk3 useflag and support of older toolkits

[hasufell]

Bug #420433 lately introduced the discussion again if and when we should
support older (deprecated) toolkit versions.

As for the named bug it may make sense to support it, cause the gtk3
useflag would lead to different (reduced) functionality of that package.
(but that shall not be the discussion here)

Generally I think gtk3 useflags should be avoided and only be a
workaround during migration to gtk+:3. Optimally gtk+:3 should always be
forced when available and not leading to major issues.
On the other hand... if gtk+:3 implementation is broken I would suggest
to simply force gtk+:2 without any gtk3 useflag. So we have ONE working
toolkit version.

Introducing stuff like gtk3 useflag will let users think this is about
choice, but it's actually not (gtk+:2 is not being developed any longer
afais).

Would it make sense to add a tracker for packages currently using gtk3
useflag, so this will not become a habit and only be a workaround?


# quse -N gtk3
app-editors/emacs/emacs-24.1_rc.ebuild
app-editors/emacs-vcs/emacs-vcs-24.1.9999-r1.ebuild
app-emulation/virt-viewer/virt-viewer-0.4.2.ebuild
app-emulation/virt-viewer/virt-viewer-0.5.2.ebuild
app-emulation/virt-viewer/virt-viewer-0.5.3.ebuild
app-i18n/fcitx/fcitx-4.2.1.ebuild
app-i18n/fcitx/fcitx-4.2.4.ebuild
app-i18n/fcitx-configtool/fcitx-configtool-0.4.1.ebuild
app-i18n/fcitx-configtool/fcitx-configtool-0.4.4.ebuild
app-i18n/ibus/ibus-1.4.1.ebuild
app-i18n/ibus-unikey/ibus-unikey-0.6.1.ebuild
app-i18n/uim/uim-1.7.1-r1.ebuild
app-i18n/uim/uim-1.7.1.ebuild
app-i18n/uim/uim-1.7.3.ebuild
app-i18n/uim/uim-1.8.0.ebuild
app-office/libreoffice/libreoffice-3.6.9999.ebuild
app-office/libreoffice/libreoffice-9999-r2.ebuild
gnome-base/librsvg/librsvg-2.34.1-r1.ebuild
gnome-base/librsvg/librsvg-2.34.2.ebuild
lxde-base/lxdm/lxdm-0.4.1-r1.ebuild
lxde-base/lxdm/lxdm-0.4.1-r2.ebuild
lxde-base/lxdm/lxdm-0.4.1-r4.ebuild
lxde-base/lxdm/lxdm-0.4.1-r5.ebuild
media-libs/libcanberra/libcanberra-0.28-r5.ebuild
media-plugins/audacious-plugins/audacious-plugins-3.2.2-r1.ebuild
media-plugins/audacious-plugins/audacious-plugins-3.2.3.ebuild
media-sound/audacious/audacious-3.2.2-r1.ebuild
media-sound/audacious/audacious-3.2.3.ebuild
media-sound/mp3splt-gtk/mp3splt-gtk-0.7.0.930.ebuild
media-sound/mp3splt-gtk/mp3splt-gtk-0.7.1.ebuild
media-sound/mp3splt-gtk/mp3splt-gtk-0.7.2.ebuild
net-dns/avahi/avahi-0.6.30-r1.ebuild
net-dns/avahi/avahi-0.6.30-r3.ebuild
net-libs/gtk-vnc/gtk-vnc-0.4.3-r1.ebuild
net-libs/gtk-vnc/gtk-vnc-0.4.4.ebuild
net-libs/gtk-vnc/gtk-vnc-0.5.0-r1.ebuild
net-libs/gtk-vnc/gtk-vnc-0.5.0.ebuild
net-misc/spice-gtk/spice-gtk-0.11.ebuild
net-misc/spice-gtk/spice-gtk-0.12.ebuild
net-misc/spice-gtk/spice-gtk-0.7.159.ebuild
net-misc/spice-gtk/spice-gtk-0.8.ebuild
net-p2p/eiskaltdcpp/eiskaltdcpp-2.2.6.ebuild
net-p2p/eiskaltdcpp/eiskaltdcpp-2.2.7.ebuild
net-p2p/eiskaltdcpp/eiskaltdcpp-9999.ebuild
sci-mathematics/gretl/gretl-1.9.7.ebuild
sci-mathematics/gretl/gretl-1.9.8.ebuild
www-client/dwb/dwb-2012.02.01.ebuild
www-client/dwb/dwb-2012.05.11.ebuild
www-client/dwb/dwb-9999.ebuild
www-client/opera/opera-11.64.1403.ebuild
www-client/opera/opera-12.00.1448.ebuild
www-client/opera/opera-12.00.1450.ebuild
www-client/opera-next/opera-next-12.00.1440.ebuild
www-client/opera-next/opera-next-12.00.1441.ebuild
www-client/opera-next/opera-next-12.00.1445.ebuild
www-client/opera-next/opera-next-12.00.1448.ebuild
www-client/opera-next/opera-next-12.00.1450.ebuild
www-client/uget/uget-1.8.0.ebuild
www-client/uget/uget-9999.ebuild
www-client/uzbl/uzbl-2011.07.17.ebuild
www-client/uzbl/uzbl-2011.07.25.ebuild
www-client/uzbl/uzbl-2011.10.01.ebuild
www-client/uzbl/uzbl-2011.11.28.ebuild
www-client/uzbl/uzbl-9999.ebuild
x11-themes/light-themes/light-themes-0.1.8.29.ebuild
x11-themes/light-themes/light-themes-0.1.8.32.ebuild
x11-themes/light-themes/light-themes-0.1.9.1.ebuild

[Alexandre Rostovtsev]

On Sun, 2012-06-10 at 04:38 +0200, hasufell wrote:
> Bug #420433 lately introduced the discussion again if and when we should
> support older (deprecated) toolkit versions.
>
> As for the named bug it may make sense to support it, cause the gtk3
> useflag would lead to different (reduced) functionality of that package.
> (but that shall not be the discussion here)
>
> Generally I think gtk3 useflags should be avoided and only be a
> workaround during migration to gtk+:3. Optimally gtk+:3 should always be
> forced when available and not leading to major issues.
> On the other hand... if gtk+:3 implementation is broken I would suggest
> to simply force gtk+:2 without any gtk3 useflag. So we have ONE working
> toolkit version.
>
> Introducing stuff like gtk3 useflag will let users think this is about
> choice, but it's actually not (gtk+:2 is not being developed any longer
> afais).
>
> Would it make sense to add a tracker for packages currently using gtk3
> useflag, so this will not become a habit and only be a workaround?

The Gnome team's recommendation is to avoid gtk3 or gtk2 USE flags.

For libraries, if possible, try splitting gtk2 and gtk3 support into
different slots (see net-libs/webkit-gtk for an example; the gtk2-based
versions have -r2xx revision numbers and go in slot 2, while the
gtk3-based versions have -r3xx revision numbers and go in slot 3).
Unfortunately, for a few libraries, this splitting is difficult to do in
a sane and maintainable manner, so then a gtk3 USE flag could be the
least bad solution.

For applications, just pick one version of gtk. If a particular version
works better, use only that one (e.g. if building an application against
gtk3 would result in reduced functionality or introduce crashes, or if
upstream calls it experimental, you should probably stick with gtk2 for
now). If the results of building against gtk2 or gtk2 are mostly
equivalent, I suggest only building against gtk3, because gtk2 is
basically legacy code that doesn't get much attention from gtk upstream.

-Alexandre

[Maxim Kammerer]

Just to illustrate the USE=gtk3 confusion, on packages I has personal
experience with:

app-i18n/uim
x11-themes/light-themes
--> flag provides support for gtk3 apps, in addition to gtk(2) (with
independent USE=gtk in uim); most users would probably want this.

gnome-base/librsvg
--> flag for gtk3 libraries *and* executables (independent USE=gtk; an
example of a package that should be slotted?)

media-sound/audacious
--> REQUIRED_USE="^^ ( gtk gtk3 )" with default switching from version
to version (current stable is gtk, previous was gtk3).

www-client/midori
--> USE=deprecated instead of USE=gtk3 in unstable.

www-client/uget
--> for once, a "simple" USE=gtk3 that enables gtk3 instead of gtk
(gtk3 support still experimental?)

media-libs/libcanberra
--> USE=gtk3 enables extra support, in addition to gtk: "Enables
building of gtk+3 helper library, gtk+3 runtime sound effects and the
canberra-gtk-play utility. To enable the gtk+3 sound effects add
canberra-gtk-module to the colon separated list of modules in the
GTK_MODULES environment variable." — very unclear: is it needed?
recommended? also, why doesn't the package handle the environment
variable by itself?

--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

[Pacho Ramos]

El dom, 10-06-2012 a las 11:45 +0300, Maxim Kammerer escribió:
> Just to illustrate the USE=gtk3 confusion, on packages I has personal
> experience with:
>

[...]

> gnome-base/librsvg
> --> flag for gtk3 libraries *and* executables (independent USE=gtk; an
> example of a package that should be slotted?)

This has been improved in 2.36.1 (thanks tetromino!)

[...]

[Sebastian Pipping]

On 06/10/2012 05:54 AM, Alexandre Rostovtsev wrote:
> For libraries, if possible, try splitting gtk2 and gtk3 support into
> different slots (see net-libs/webkit-gtk for an example; the gtk2-based
> versions have -r2xx revision numbers and go in slot 2, while the
> gtk3-based versions have -r3xx revision numbers and go in slot 3).

That's a crazy but interesting approach.

Best,



Sebastian

[Ciaran McCreesh]

On Sat, 09 Jun 2012 23:54:21 -0400
Alexandre Rostovtsev <tetr...@gentoo.org> wrote:
> For libraries, if possible, try splitting gtk2 and gtk3 support into
> different slots (see net-libs/webkit-gtk for an example; the
> gtk2-based versions have -r2xx revision numbers and go in slot 2,
> while the gtk3-based versions have -r3xx revision numbers and go in
> slot 3).

That is not what revisions are for. If you can't solve a problem
properly using existing mechanisms, ask for new ones.

--
Ciaran McCreesh

[hasufell]

I disagree. This is a proper solution, cause we use SLOTs and on top of
that revision numbers to make a difference for the ebuild name.

Another solution would be to include the SLOT in the ebuild name, but I
see more potential problems with that.

[Nirbheek Chauhan]

It's a simple workaround for the lack of proper ebuild namespacing on
the basis of slots.

So, till we have that, this works pretty well. :)

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

[Ciaran McCreesh]

On Sun, 10 Jun 2012 22:27:07 +0200
hasufell <hasu...@gentoo.org> wrote:
> On 06/10/2012 10:19 PM, Ciaran McCreesh wrote:
> > On Sat, 09 Jun 2012 23:54:21 -0400
> > Alexandre Rostovtsev <tetr...@gentoo.org> wrote:
> >> For libraries, if possible, try splitting gtk2 and gtk3 support
> >> into different slots (see net-libs/webkit-gtk for an example; the
> >> gtk2-based versions have -r2xx revision numbers and go in slot 2,
> >> while the gtk3-based versions have -r3xx revision numbers and go in
> >> slot 3).
> >
> > That is not what revisions are for. If you can't solve a problem
> > properly using existing mechanisms, ask for new ones.
>
> I disagree. This is a proper solution, cause we use SLOTs and on top
> of that revision numbers to make a difference for the ebuild name.

Uh, no. -rX, where X goes up by 1 each time, is used to indicate a
revised ebuild (for example, when adding patches) where the upstream
version remains the same. What you're trying to do is completely
different.

The fact that something happens to "work" is not enough to make it
right.

--
Ciaran McCreesh

[Ciaran McCreesh]

Until you have that, or something else designed to do what you want,
don't come up with some disgusting hack.

--
Ciaran McCreesh

[hasufell]

I took the freedom to open a few bugs about that with a tracker:
https://bugs.gentoo.org/show_bug.cgi?id=420493

This is not an urgent thing, but I think it's good to have an overview
of gtk3 useflag usage, cause they are all more or less migration issues,
some maybe not even fixable or exceptions.

[Nirbheek Chauhan]

So the PMS process should be a bottleneck to getting software out to
users? I think that's counter-productive.

Our goal here is not to facilitate package manager development but to
package and distribute software to users.

On the other hand, you seem to be uniquely inclined to give a priority
to this, and hence I implore you to continue your investigations into
adding this feature to PMS and portage. :)

Cheers,

[Ciaran McCreesh]

On Mon, 11 Jun 2012 13:15:40 +0100

Nirbheek Chauhan <nirb...@gentoo.org> wrote:
> On Sun, Jun 10, 2012 at 9:49 PM, Ciaran McCreesh
> <ciaran....@googlemail.com> wrote:
> > On Sun, 10 Jun 2012 21:45:27 +0100
> > Nirbheek Chauhan <nirb...@gentoo.org> wrote:
> >> It's a simple workaround for the lack of proper ebuild namespacing
> >> on the basis of slots.
> >>
> >> So, till we have that, this works pretty well. :)
> >
> > Until you have that, or something else designed to do what you want,
> > don't come up with some disgusting hack.
>
> So the PMS process should be a bottleneck to getting software out to
> users? I think that's counter-productive.

There is no PMS bottleneck. There is a Portage bottleneck, and there is
a "figuring out how to ensure new features don't interact badly with
either old features or stupid hacks people have done". Abuse of the
kind under discussion is a large contributor to both of those
bottlenecks.

> Our goal here is not to facilitate package manager development but to
> package and distribute software to users.

No, your goal is to provide a distribution. Gentoo has repeatedly shot
itself in the foot, leg, groin etc by favouring short-term hacks over a
well thought out, validated, self-enforcing design. Right now nearly
all of the package manager work is on paying off previously incurred
technical debt, and in the mean time you're busy adding to it.

--
Ciaran McCreesh

[Pacho Ramos]

The problem here is that we (or, at least, I) are a bit unsure about how
this could be handled better and, then, try to use that better way in
the future. If you (or any) have some suggestion, it would be nice :)

[Ciaran McCreesh]

On Mon, 11 Jun 2012 20:41:37 +0200
Pacho Ramos <pa...@gentoo.org> wrote:
> > No, your goal is to provide a distribution. Gentoo has repeatedly
> > shot itself in the foot, leg, groin etc by favouring short-term
> > hacks over a well thought out, validated, self-enforcing design.
> > Right now nearly all of the package manager work is on paying off
> > previously incurred technical debt, and in the mean time you're
> > busy adding to it.
>
> The problem here is that we (or, at least, I) are a bit unsure about
> how this could be handled better and, then, try to use that better
> way in the future. If you (or any) have some suggestion, it would be
> nice :)

It is handled better by working out what exactly the problem is, and if
you can't implement it nicely using existing features, then not
implementing it at all until you have suitable features.

--
Ciaran McCreesh

[Gilles Dartiguelongue]

That's not crazy, it's the least confusing way to go as package managers
cannot have the same version in two slots. We added a suffix that allows
differenciation and still easy reading of which slot the upgrade is
about.

--
Gilles Dartiguelongue <e...@gentoo.org>
Gentoo

[Gilles Dartiguelongue]

Sorry to make this old thread pop up again but, no, it is not acceptable
to not ship packages like webkit just because you dislike the solution
we used to workaround a well known problem in ebuild packaging.

FTR, this solution may have problems, that you are free to highlight,
but it is has been carefully thought out to not be too much of a burden
for devs and users alike.

When someone comes up with a solution that is accepted for PMS, we will
be more than happy to switch to it. So please stop complaining and do
what you are best known for, find a solution that can fit PMS. TIA.

[Ciaran McCreesh]

Perhaps you should be asking for a feature that allows you to solve it
properly, rather than abusing existing features to do something they're
not intended for.

--
Ciaran McCreesh

[Ciaran McCreesh]

On Sat, 23 Jun 2012 15:02:41 +0200
Gilles Dartiguelongue <e...@gentoo.org> wrote:
> > It is handled better by working out what exactly the problem is,
> > and if you can't implement it nicely using existing features, then
> > not implementing it at all until you have suitable features.
>
> Sorry to make this old thread pop up again but, no, it is not
> acceptable to not ship packages like webkit just because you dislike
> the solution we used to workaround a well known problem in ebuild
> packaging.

No-one is saying "don't ship webkit". What is being asked is that a) you
ship webkit with a subset of functionality disabled if necessary for
now, and b) that you provide a general description of what you can't
provide cleanly using existing functionality.

If you really think it's necessary to come up with a workaround like
this, though, then you should be mailing the list and asking for QA or
Council approval, rather than doing it and then asking for forgiveness
later.

--
Ciaran McCreesh

[Gilles Dartiguelongue]

Le samedi 23 juin 2012 à 14:08 +0100, Ciaran McCreesh a écrit :
> On Sat, 23 Jun 2012 15:02:41 +0200
> Gilles Dartiguelongue <e...@gentoo.org> wrote:
> > > It is handled better by working out what exactly the problem is,
> > > and if you can't implement it nicely using existing features, then
> > > not implementing it at all until you have suitable features.
> >
> > Sorry to make this old thread pop up again but, no, it is not
> > acceptable to not ship packages like webkit just because you dislike
> > the solution we used to workaround a well known problem in ebuild
> > packaging.
>
> No-one is saying "don't ship webkit". What is being asked is that a) you
> ship webkit with a subset of functionality disabled if necessary for
> now, and b) that you provide a general description of what you can't
> provide cleanly using existing functionality.

Well the problem is simple, we need to ship webkit with gtk2 and gtk3
support. This is needed because gentoo has gtk2 based desktop/apps and
because we want to ship gnome3 for example.

Cool thing is that webkit supports being built with each toolkit without
conflicting with the build from the other toolkit hence we ended up
using SLOTS.

Then the problem is that you cannot have two ebuilds of the same version
in two different slots.

We then had a couple of solutions, most notable being:
* using -r${SLOT}${PATCHLEVEL} suffix, being a strictly increasing
number that is not expected to go over 300 which is the start of the
sequence for the other slot.
* using a new package name, duplicating ebuilds

> If you really think it's necessary to come up with a workaround like
> this, though, then you should be mailing the list and asking for QA or
> Council approval, rather than doing it and then asking for forgiveness
> later.

As far as I remember the subject was discussed (at least) once on this
mailing list before the problem even occurred for gtk2/gtk3 handling and
everyone was ok with it.

Shall we add that subject to next council meeting or do we just wait for
QA's opinion here ?

[Ciaran McCreesh]

On Sat, 23 Jun 2012 15:33:47 +0200
Gilles Dartiguelongue <e...@gentoo.org> wrote:
> Well the problem is simple, we need to ship webkit with gtk2 and gtk3
> support. This is needed because gentoo has gtk2 based desktop/apps and
> because we want to ship gnome3 for example.
>
> Cool thing is that webkit supports being built with each toolkit
> without conflicting with the build from the other toolkit hence we
> ended up using SLOTS.

You could just have gtk2 and gtk3 use flags in the ebuild, use
REQUIRED_USE to ensure that at least one is enabled, and build things
twice in the ebuild if necessary.

Yes, your ebuild will probably be fairly ugly. This won't be visible to
users, though.

Users will have to rebuild a version unnecessarily if they want to go
from having just gtk2 to gtk2 and gtk3 (or so on). That should be rare
enough, compared to frequency of bumps etc, that it's not a severe
enough problem to warrant a hack until a nice alternative is available.

> Shall we add that subject to next council meeting or do we just wait
> for QA's opinion here ?

I'd like to know why using USE flags until a nicer solution is available
is sufficiently terrible that it warrants a hackaround.

--
Ciaran McCreesh

[Gilles Dartiguelongue]

Forgot to mention that, at least for webkit, this is really a case for
slots usage as this is the same software, built for another toolkit.
This applies to a couple other ebuilds in this gtk2/gtk3 discussion, but
admittedly not all of them.

We have at least three cases that Alexandre summed up:
* packages shipping gtk based libs only
* packages shipping gtk based libs and other libs (gtk-vnc for example)
* packages shipping gtk based libs and gtk or non-gtk utilities

Some packages most likely should be split, like avahi, but it is not
always in the interest of everyone as it makes things much harder to
maintain.

[Gilles Dartiguelongue]

Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit :
>
> I'd like to know why using USE flags until a nicer solution is
> available
> is sufficiently terrible that it warrants a hackaround.

remember qt3/qt4, gtk/gtk2. We want to avoid repeating these "mistakes"
hence the guidelines already exposed back when we introduced gtk3 to the
tree.

As you may have noticed, this is still the solution applied for things
hard to split or slot like gtk-vnc or avahi but we didn't see the need
to have such USE flags when the library was so easily slottable.

[Michał Górny]

Indeed. But reusing revisions is probably saner than abusing
the version number to achieve the same goal.

--
Best regards,
Michał Górny

[Ciaran McCreesh]

On Sat, 23 Jun 2012 16:45:09 +0200
Gilles Dartiguelongue <e...@gentoo.org> wrote:
> Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit :
> > I'd like to know why using USE flags until a nicer solution is
> > available
> > is sufficiently terrible that it warrants a hackaround.
>
> remember qt3/qt4, gtk/gtk2. We want to avoid repeating these
> "mistakes" hence the guidelines already exposed back when we
> introduced gtk3 to the tree.

We didn't have REQUIRED_USE or use dependencies back then. We do now.

> As you may have noticed, this is still the solution applied for things
> hard to split or slot like gtk-vnc or avahi but we didn't see the need
> to have such USE flags when the library was so easily slottable.

Again, REQUIRED_USE.

--
Ciaran McCreesh

[Michał Górny]

On Sat, 23 Jun 2012 14:40:50 +0100
Ciaran McCreesh <ciaran....@googlemail.com> wrote:

> On Sat, 23 Jun 2012 15:33:47 +0200
> Gilles Dartiguelongue <e...@gentoo.org> wrote:
> > Well the problem is simple, we need to ship webkit with gtk2 and
> > gtk3 support. This is needed because gentoo has gtk2 based
> > desktop/apps and because we want to ship gnome3 for example.
> >
> > Cool thing is that webkit supports being built with each toolkit
> > without conflicting with the build from the other toolkit hence we
> > ended up using SLOTS.
>
> You could just have gtk2 and gtk3 use flags in the ebuild, use
> REQUIRED_USE to ensure that at least one is enabled, and build things
> twice in the ebuild if necessary.

Ah, so because a few paludis users may be building an additional
variant of webkit-gtk unnecessarily, we should force all Gentoo users
to randomly rebuild 1-2 variants depending on how soon they're going to
get the USE correctly.

[Ciaran McCreesh]

On Sat, 23 Jun 2012 20:26:01 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> > You could just have gtk2 and gtk3 use flags in the ebuild, use
> > REQUIRED_USE to ensure that at least one is enabled, and build
> > things twice in the ebuild if necessary.
>
> Ah, so because a few paludis users may be building an additional
> variant of webkit-gtk unnecessarily, we should force all Gentoo users
> to randomly rebuild 1-2 variants depending on how soon they're going
> to get the USE correctly.

No. Because the ebuilds would be abusing functionality in a fairly
horrible way, we should avoid doing that until we have a good solution
in place.

Or, looking at it another way, Portage's upgrade rules shouldn't be
locked in place because of weird behaviour from a few packages.

--
Ciaran McCreesh

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/11/2012 07:08 PM, Ciaran McCreesh wrote:
> No, your goal is to provide a distribution. Gentoo has repeatedly
> shot itself in the foot, leg, groin etc by favouring short-term
> hacks over a well thought out, validated, self-enforcing design.
> Right now nearly all of the package manager work is on paying off
> previously incurred technical debt, and in the mean time you're
> busy adding to it.
>

Please take your exherbo trolling somewhere else.

Our goal is not to provide a distribution, because gentoo sees itself
as a metadistribution.

Please familiarize yourself with:
http://www.gentoo.org/main/en/about.xml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP5guCAAoJEFpvPKfnPDWz6sMH+wVghjCDgYUv6sQzuFCm/xyO
gi5fUBRQR7OcpG2KmWsZE6WHLFd1StsoVYwkJB3phwwLeP3P6oEuGvyfjOjY3iIb
m8jqbVWbFm9YDS58koGktU7zhOWXbsj/hi3XrbCz2qYlKF23rJfubGehlaNZHIQf
OpkBoO1kuPC6AJtJdcY8iXEbneZ7NY/OMOHGasZB/B6O51anbBZ3nuSu1GDbQJ47
NbnJIG/Iuf2FiLgCOCNicRjnnd0AEoQMIhXkrhLcixYNJJ3BMWxPLUA/uJshXUtg
HiJqVGEv0ljGgo45rQIDZo5w44tgdOQ7nH6C6criBFKU6/wlbbnbH6ZFpW1Dg9o=
=iWGS
-----END PGP SIGNATURE-----

[Doug Goldstein]

On Sat, Jun 23, 2012 at 1:31 PM, hasufell <hasu...@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/11/2012 07:08 PM, Ciaran McCreesh wrote:
>> No, your goal is to provide a distribution. Gentoo has repeatedly
>> shot itself in the foot, leg, groin etc by favouring short-term
>> hacks over a well thought out, validated, self-enforcing design.
>> Right now nearly all of the package manager work is on paying off
>> previously incurred technical debt, and in the mean time you're
>> busy adding to it.
>>
>
> Please take your exherbo trolling somewhere else.
>
> Our goal is not to provide a distribution, because gentoo sees itself
> as a metadistribution.
>
> Please familiarize yourself with:
> http://www.gentoo.org/main/en/about.xml

Let's keep the discussions on this mailing list technical and not personal.

Thanks.
--
Doug Goldstein

[Doug Goldstein]

Let's all agree that the current solution is less than ideal and could
use improvement. I have several Gentoo & Portage only desktops and I
find myself annoyed with webkit-gtk and its revisions and rebuilds.

--
Doug Goldstein

[Doug Goldstein]

It's funny you bring up qt3/qt4 and gtk/gtk2 since I'm only of the few
developers that worked on resolving both of those as they came and
went. Right now the resources we've got available to us from a Package
Manager stand point. Being a Gentoo dev for so long has allowed me to
see how our distro has evolved so let me give you a short walk down
memory lane, when gtk/gtk2 & qt3/qt4 occurred we had the following:
- Portage 1.x (gtk/gtk2) / Portage 2.0.x (qt3/qt4)
- No EAPI
- No way to add features quickly to the Package Manager and the spec for it.

During gtk/gtk2, the rule was you had to wait until a feature was
available in the STABLE version of Portage, 4 releases back before you
could use a new feature. For everyone's knowledge, we did 4 releases a
year then. We knew our solution to gtk/gtk2 sucked and we hated it but
there was absolutely nothing we could do about it. It was a bitter
battle of band aids and hacks that we couldn't wait to get rid of. We
even attempted to throw gtk1 out of the tree entirely (ah the XMMS
flamewar) to get rid of the hacks. You couldn't even modify eclasses
since they weren't stored with the install, which lead to the -rX
revisioning of eclasses. On top of all this, Portage 1.x SUCKED to
modify or hack at. The only solution with that codebase was to nuke it
from orbit, which we finally did with Portage 2.0.x.

During qt3/qt4, the rule was you had to wait until the feature you
were trying to use was in a STABLE Portage for 6 months. We didn't
have a lot of options available but we worked with the current Portage
maintainer at the time to get some of the resolver improved and fixed
and get those updates pushed out to the tree as quickly as possible.
Once the updates were available the hacks went away and life was
better.

Now fast forward to 2011/2012, we were obviously aware that the
gtk2/gtk3 change would cause some problems. Heck people encountered it
when they tried to add ebuilds to the tree. The right path forward was
to speak to Zac, Brian and the rest of the PMS guys and see what the
best solution was. If it was implementing some new features then we
could have done that and gotten and EAPI approved quickly and had it
available before we even saw the first gtk3 ebuild unmasked. But alas,
that wasn't the case and here we are today. So here's what I suggest,
let's stop bickering and revisit the "hacks" you did to make things
work. Speak to Zac, Brian and the rest of the PMS guys and get what
you need implemented as a feature and get that feature into the very
next EAPI bump. Fix the tree to use that EAPI and get rid of the
hacks. You'll thank yourselves in the long run since things will be
easier to maintain and you can focus on what you enjoy doing.

--
Doug Goldstein

[Ben de Groot]

On 23 June 2012 22:45, Gilles Dartiguelongue <e...@gentoo.org> wrote:
> Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit :
>>
>> I'd like to know why using USE flags until a nicer solution is
>> available is sufficiently terrible that it warrants a hackaround.
>
> remember qt3/qt4, gtk/gtk2. We want to avoid repeating these "mistakes"
> hence the guidelines already exposed back when we introduced gtk3 to the
> tree.

I don't see what the problem is now. We have slots, usedeps and
required_use. Why would we need to avoid using gtk2/gtk3 useflags?

We of the Qt team are expecting Qt5 to enter the tree within the
next few months, and I'm not expecting any trouble with using
qt4 and qt5 useflags.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead

[hasufell]

On 06/24/2012 10:07 AM, Ben de Groot wrote:
> I don't see what the problem is now. We have slots, usedeps and
> required_use. Why would we need to avoid using gtk2/gtk3 useflags?
>
> We of the Qt team are expecting Qt5 to enter the tree within the
> next few months, and I'm not expecting any trouble with using
> qt4 and qt5 useflags.

Afais qt team has done this from the start? If there was no "gtk"
useflag, but only "gtk2" the situation would maybe be different.
Now we have gtk, gtk2 and gtk3 and the user has to figure out what they
mean for each package, cause they are not used consistently.

This is a problem.

Either cleanly avoid slot reference in useflag name or go it all the
way, but afaik the gnome herd is not interested much in supporting older
versions of gtk+, so the first way seems the best.

[Michał Górny]

Any other solution would involve the same rebuilds...

[Gilles Dartiguelongue]

Just to remember everyone what gnome team actually tried to achieve to
reduce any pain from users or devs alike with gnome3 work:
* have libs slotted when possible (to the extent of manpower
available), so gtk USE flag means gtk, whatever slot is needed by the
package using it,
* have applications use one toolkit or the other according to maturity
of the interface and will of the maintainer. This avoids useless
back/forward porting work when upstream actually doesn't care about one
of the toolkits in question

The problem raised in this thread is when the package is hard to
maintain in a splitted form, not in the control of gnome team, or
upstream does not want to split at all.

We do this split work when it is sustainable by the team, not just
because it's better, please bear that in mind.

FTR, I still don't see the real problem in the current solution hence
the issue was not brought formally to PMS team earlier. Again, this
approach was exposed months ago to this very ml and most likely to
#gentoo-dev as well and nobody raised an objection on the method used.

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/24/2012 12:11 PM, Gilles Dartiguelongue wrote:
> Just to remember everyone what gnome team actually tried to
> achieve to reduce any pain from users or devs alike with gnome3
> work: * have libs slotted when possible (to the extent of manpower
> available), so gtk USE flag means gtk, whatever slot is needed by
> the package using it, * have applications use one toolkit or the
> other according to maturity of the interface and will of the
> maintainer. This avoids useless back/forward porting work when
> upstream actually doesn't care about one of the toolkits in
> question

I agree and this is exactly what my tracker is about, to track porting
issues or even misuse of gtk{,2,3} useflags. You confuse me.

My tracker has shown that not all ebuilds follow that policy or even
can't because of migration issues or cause they are special in another
way.

If you think I missed something in my explanation there, add a comment.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP5uzxAAoJEFpvPKfnPDWzzO8H/1+Zs4BiZWIPwsLmCTfHWdH8
kGBylD/TKhJqOU9BimIzlqqKVa0Ikw/hak2vWSdsor/P5dJ/oAQqvUK+S9HWsEaI
fCxzoZQZ/ghbYE4a3Ob8V0KWc0602OYO0WKZ9DAHqb47377VYO/CIQ2tsBG9oKM5
gah5fBZnf9mbMGRKREkPLwMG5L6Nl9j34JNO+BB5xBAWhLnNp3JmWfKLMzILWaKf
R14uHG78ETDVp3uvQdgbMYzEzRE+a8iaH0lF9ekJwJ5qcGGWhP4mafDHTO4PGPjM
OC9Hqt9eMqQFLdjaAxguH9HDyWEhoEg90RQfSK+FsOj2HOMX5s/XevXrdrNF2Uk=
=hxx4
-----END PGP SIGNATURE-----