Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[landis blackwell]

I stopped reading after you reminded me it was 2016
On May 27, 2016 9:21 AM, "Mart Raudsepp"  wrote:

> Hello,
>
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
> upstream, many applications still support only gtk2, have subtle issues
> with their gtk3 port, or support both, with some of our userbase
> clinging to gtk2 for dubious political or aesthetical reasons.
>
> For the latter cases, despite GNOME teams policy and strong preference
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
> working as good as gtk2), some cases exist where the maintainers want
> to provide such choice. In some cases it is understandable for a short
> while during transition, e.g firefox. In other cases, it is purely for
> the sake of providing the choice of working with a deprecated toolkit,
> apparently.
>
> My highly biased essay aside, we need to finally globally agree on what
> we do in this situation. If we allow this choice at all, only for
> special cases, or widespread. And if this choice is provided, how do we
> name the USE flag.
>
> Historically, for very good reasons in past and present GNOME team
> members opinion, USE=gtk has always meant to mean to provide support
> for gtk in general, not any particular version. This is opposite to
> what the Qt team has been doing.
> In our opinion, in a perfect world, only USE=gtk would exist, and no
> USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a
> perfect world, we have made use of USE=gtk3 for providing gtk3 support
> from library packages to mean to build gtk3 support. Sadly that
> overloads USE=gtk in many cases to then mean to build gtk2 support.
> This would ideally not be needed, as the package would instead be
> slotted and parallel installable for gtk2 and gtk3, which should be
> theoretically possible in all cases, because gtk2 and gtk3 may not live
> in the same process, so not the same library either.
> Due to some packages needing too much manpower effort to do such a
> split, USE flags are used in such a case.
> Good examples of such slot splits existing are for example the
> libappindicator stack. This used to be the case with almost all GNOME
> libraries as well, but most of them only provide gtk3 now, as gtk2 is,
> well, dead.
> Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to
> split up into separate SLOTs. In some cases it might have been meant as
> a transitional thing, until all consumers are ported to gtk3, but it
> has been lingering on due to consumer apps not being ported or we
> haven't yet noticed to remove the gtk2 support in the library package.
>
> Now these are libraries, and despite some USE flag confusion, it's not
> a huge issue, because consumers are USE depending on what is required.
> This all is written out in
> https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3
> since the GNOME project pages moving to wiki, and also long before that
> in GuideXML era, and we've pointed people towards that.
>
> And then we have applications that support building against either gtk2
> or gtk3.
> In most cases, any requests to provide the choice to have an
> application use gtk2 instead of gtk3 gets instantly marked as duplicate
> of https://bugs.gentoo.org/374057 but in some cases the maintainer has
> chosen to provide this choice for now, and here is the problem - we
> don't really have a good agreed on way to name such a choice in USE
> flags, if we should provide such a choice at all.
>
> USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and
> USE=gtk and it being problematic. The GNOME team shall probably veto
> such USE flag usage if we are deemed to have such an authority as gtk+
> maintainers, unless we rework it all in expectations of gtk2 corpse
> being carried around for a decade as well... I have quite a few bugs
> against packages to file already for this, afair.
>
> I kind of like what firefox did there, going in the spirit of the
> force-openrc flag we have for avoiding systemd dependency, even if it
> currently means worse user experience. So if we provide such a choice
> for apps at all, I might agree to USE=force-gtk2 for this for apps. And
> we would like to eventually (or immediately) p.use.mask this and once
> it's 2017 and gtk2 truly dead and buried and full of known security
> holes, get rid of it again.
> But this highlighted the inconsistency we are having, ending up with QA
> initiated bug https://bugs.gentoo.org/581662
>
> tl;dr and my proposal would be the following:
>
> * USE=gtk means providing support for GTK+; because we don't have a
> USE=gui, this also means "provide a GUI version built on top of gtk+"
> for packages where a GUI is optional.
>
> * USE=gtk3 may be used only for controlling extra libraries to be
> shipped for gtk3 support (the extra library file will link to gtk3),
> _in addition_ to gtk2 version. This is a temporarily measure until gtk2
> support can be dropped 

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[landis blackwell]

No fun allowed
On May 14, 2016 12:06 PM, "Rich Freeman"  wrote:

> On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt 
> wrote:
> > On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
> >> Gordon Pettey schrieb:
> >>
> >>> So, it's perfectly okay to make direct commits of obviously broken
> >>> code that
> >>> has no chance of working, because community something mumble...
> >>
> >> You may have missed some sarcasm in the post which you replied to.
> >> Plus, I don't think anybody said or implied that committing broken
> >> things is ok.
> >>
> >>
> >> Best regards,
> >> Chí-Thanh Christopher Nguyễn
> >>
> > I think the time is coming, given the diversity of members of this list,
> > to add  tags when we are not describing something
> > literally. It becomes very difficult to follow the thread of
> > conversation when people are (not) communicating their true thoughts!!
> >
>
> While this is certainly sensible, the irony here is that this whole
> discussion was started by somebody making a sarcastic remark when
> simply pointing out a mistake would have been just as functional.
>
> Nobody thinks it is ok to commit broken code.  What it seems like
> we'll be debating until there is only one of us left is how
> unprofessional we should be when pointing that out.
>
> --
> Rich
>
>