Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

[Donnie Berkholz]

On 00:13 Wed 12 Feb , Gilles Dartiguelongue wrote:
> Right now, I don't really get the point of this discussion given all the
> precedent threads about this, be it 2 years ago and 8-10 years ago.

I spent a while tonight digging up this post from 2005, which nicely 
describes where we were with gtk1 vs gtk2 back then.

http://marc.info/?l=gentoo-dev&m=111212920310822&w=2

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux 
Analyst, RedMonk 


pgpiDAYuRO_lp.pgp
Description: PGP signature

Re: [gentoo-dev] February 2014 QA policy updates

[Alex Xu]

On 20/02/14 04:46 PM, Mike Gilbert wrote:
> On Wed, Feb 19, 2014 at 5:07 PM, Chris Reffett  wrote:
>> This does not affect sys-boot/grub's USE=multislot, as that
>> does not mangle the SLOT value like the others (as I understand it).
> 
> Right. USE=multislot on grub just toggles the renaming of the grub-foo
> commands to grub2-foo, in case someone (like me) prefers the upstream
> naming convention. There is also a conditional blocker on
> sys-boot/grub:0. The SLOT value is always '2'.
> 
> I would be happy to rename the use flag if anyone else has a better name for 
> it.
> 

All other packages use it to mean "make multiple versions in a single
SLOT installable".

I think "vanilla" should be used, or possibly a different local USE
flag, like "grub2-bins". The argument of wanting this globally is not
valid, since multislot should not be set globally either.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] February 2014 QA policy updates

[Mike Gilbert]

On Wed, Feb 19, 2014 at 5:07 PM, Chris Reffett  wrote:
> This does not affect sys-boot/grub's USE=multislot, as that
> does not mangle the SLOT value like the others (as I understand it).

Right. USE=multislot on grub just toggles the renaming of the grub-foo
commands to grub2-foo, in case someone (like me) prefers the upstream
naming convention. There is also a conditional blocker on
sys-boot/grub:0. The SLOT value is always '2'.

I would be happy to rename the use flag if anyone else has a better name for it.

[gentoo-dev] Last rites: app-emacs/http-emacs

[Ulrich Mueller]

# Ulrich Müller  (20 Feb 2014)
# Abandoned by upstream: Last release in 2003, last visible
# upstream activity in 2004. Does not work with Emacs 24.
# File a bug for moving app-emacs/oddmuse (currently in emacs
# overlay) to the main tree if you need a replacement.
# Masked for removal in 30 days, bug 501926.
app-emacs/http-emacs


pgphB0xuF0Ya0.pgp
Description: PGP signature

Re: [gentoo-dev] February 2014 QA policy updates

[Michał Górny]

Dnia 2014-02-19, o godz. 17:07:26
Chris Reffett  napisał(a):

> -Regarding the gtk/gtk2/gtk3 USE flag situation: we mandate that gtk
> move to versioned USE flags. For simplicity of migration, we will allow
> USE=gtk to mean "depend on gtk2," since there are only a few USE=gtk2
> remaining in tree. USE=gtk3 will mean "depend on gtk3," and in the
> future, USE=gtk4 will mean "depend on gtk4," and so on. USE=gtk may
> not be used to mean "depend on some version of gtk."

I don't want to add fuel to the fire but I'd like to note that
the Council is likely going to vote on the issue [1]. Just in case some
people didn't notice, and in hope that at least some of the extra
bikeshed could be avoided.

[1]:http://article.gmane.org/gmane.linux.gentoo.project/3319

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] February 2014 QA policy updates

[Gilles Dartiguelongue]

Le 19 févr. 2014 à 23:07, Chris Reffett  a écrit :

> Hello all,
> The following are the policy changes from this month's QA team meeting:
[…]
> -Regarding the gtk/gtk2/gtk3 USE flag situation: we mandate that gtk
> move to versioned USE flags. For simplicity of migration, we will allow
> USE=gtk to mean "depend on gtk2," since there are only a few USE=gtk2
> remaining in tree. USE=gtk3 will mean "depend on gtk3," and in the
> future, USE=gtk4 will mean "depend on gtk4," and so on. USE=gtk may
> not be used to mean "depend on some version of gtk."
> 
> -More generally: we recommend that in future situations like this (a package
> can optionally depend on different versions of a library), we recommend the
> use of versioned USE flags. It should be discussed with the QA team either
> way.
> 
[…]
> Chris Reffett
> Gentoo QA Lead

I feel this policy is even less precise than what we had written in our wiki 
page and will in fact bring more confusion.
Can we actually get together in the writing of this, I feel a bit unhappy about 
the process.

-- 
Gilles Dartiguelongue 

Re: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only

[Alec Warner]

On Thu, Feb 20, 2014 at 8:39 AM, Michał Górny  wrote:

> Dnia 2014-02-20, o godz. 14:12:17
> Lars Wendler  napisał(a):
>
> > So what can we do? Three solutions came to my mind which I list
> > here in the order first being my favorite, last being my least
> > favorite:
> >
> > 1.)
> > Make portage's unpack function lzip compatible
>
> Three packages still don't sound like something to add to EAPI. Even
> with ten, I would have my doubts. Reading the whole thread, lzip
> doesn't seem like it's going to live long. Trying to artificially force
> it upon people is only going to give opposite results.
>
> > 2.)
> > Fix this on ebuild level:
> > - add app-arch/lzip to DEPEND
> > - add something like
> >   'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die'
> >   to a custom src_unpack() function.
>
> Either that, or add it to unpacker.eclass and use it. That's the place
> where we handle all the random cruft, and where we can fix it as
> problems arise.
>
> > 3.)
> > Provide all affected source tarballs ourselves in a portage compatible
> > compressed format.
>
> I think that'd be a waste of effort, to be honest. I think using lzip
> (and lzip only) is the problem, and we shouldn't bury it like this.
>
>
I agree that this idea is a bad one, I recommend 2 or 4. 1 is obviously not
going to happen without more lzip adoption.



> > 4.)
> > Try very hard to convince upstream to provide sources in differently
> > compressed tarballs.
>
> If you can't convince them yourself, let our users do that. Gentoo is
> pretty specific in the way people handle extra dependencies they find
> unnecessary :).
>
> --
> Best regards,
> Michał Górny
>

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

[Tom Wijsman]

On Thu, 20 Feb 2014 12:27:30 +0200
Samuli Suominen  wrote:

> 
> On 20/02/14 12:07, Duncan wrote:
> > Samuli Suominen posted on Thu, 20 Feb 2014 07:55:44 +0200 as
> > excerpted:
> >
> >> On 20/02/14 00:23, Ulrich Mueller wrote:
> >>> Following up to today's QA meeting: The gtk3 USE flag is used by
> >>> 27 packages, so I suggest making it a global flag:
> >>>
> >>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> >>>
> >>> Ulrich
> >> that would suggest it's fine to use, and is anything but temporary
> >>
> >> -1 from here
> > You must have missed the news implied by that "following up"
> > wording, then.  See the announcement/thread "February 2014 QA
> > policy updates", posted by creffett, just a few minutes before this
> > thread started.
> 
> I find it sad the QA team has been taken over by some of the new and
> semi-new
> developers who don't completely understand the implications of this
> decision yet
> since they haven't lived through the older transitions.

The older transitions came up a few times during the discussions on
this (in and out of meeting); we're aware of it to a certain extent,
as for whether that is understood I'd say that if around 7 people vote
on the matter that that is based on a necessary amount of understanding.

Feel free to point out further concerns from older transitions.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Ciaran McCreesh]

On Thu, 20 Feb 2014 16:41:58 +
hasufell  wrote:
> But the question is... what sane alternative to REQUIRED_USE? That
> will also have impact on a lot of eclasses.

Either pkg_pretend, or Exherbo's MYOPTIONS.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: new global USE flag gtk3

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ciaran McCreesh:
> On Thu, 20 Feb 2014 11:48:11 +0100 Ulrich Mueller 
> wrote:
>> We don't want users having to solve a Zebra Puzzle [1] (or, for
>> the more theoretically inclined, a satisfiability problem [2]) to
>> find an acceptable combination of their USE flags.
> 
> Actually, REQUIRED_USE was introduced precisely to require users
> to solve SAT without help... As you may recall, we *were* going to
> use pkg_pretend for this sort of thing to give the users a friendly
> error message, but this was replaced at the last minute with
> REQUIRED_USE to force package manglers to reduce the quality of
> error message that's produced.
> 
> So really we should just scrap REQUIRED_USE in EAPI 6, and migrate
> any ebuilds currently using it to a sane alternative.
> 


One thing that bothers me most about gentoo is a discussion I had with
a colleague who uses FreeBSD. It ended up like... gentoo is
interesting, but wtf all those USE flags and no idea how to even get
something to build without reading through forum threads, mailing
lists, et c. ... and finally trying to get help on IRC.
That guy is not new to linux. And he is right.

Usability is not our strongest thing. That's why I pushed for a clear
decision on this matter, because the whole thing is already confusing
and weird enough for new users. The new python eclasses and multilib
added to that complexity (but that will hopefully be gone when the
transition is over, more or less). People who regularly hack and play
with gentoo don't have any problem with those things and quickly get
ideas about emerge conflicts based on experience... where a new user
would never get to the root of the problem and just give up.

But the question is... what sane alternative to REQUIRED_USE? That
will also have impact on a lot of eclasses.


Also... I find mgornys idea not too bad, meaning USE flag naming
should be feature oriented and not implementation oriented. That is
definitely an issue QA has to comment on. But I really feel we will
get some hate from people who try to avoid certain implementations for
one or another reason. And there can be valid reasons. So those people
will have to use alternatives like package.mask.
Another problem I see is that e.g. "gui" could be a bit too generic.
If some dev uses it for an ncurses gui in his ebuild... then we have
successfully screwed up easy setup of X-less servers, because "-gui"
will also kill all non-X guis.
Anyway... what we can do to improve the overall situation while
discussing this: use proper local USE flag descriptions.
"Add support for x11-libs/gtk+ (The GIMP Toolkit)" is totally useless
in 95% of the cases. Still... a lot of ebuilds don't override that
description. So I often end up actually unpacking the source tarball
and reading the configure description. Fail.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJTBjBWAAoJEFpvPKfnPDWza6EIAIoctpgmuUN8m793AtkaLExI
WvI85BzjxLZ/71w4wNC2Fgeqid4qvTMlopCnqfqSrXBJqXPwiuhsDMTh2DPQOuRU
hm3DvZSbApCJnGXqwE3XeJSarQnmBZ+Ynbkv/keqLWsErG/6BxRxsK4a1DW36vhf
MB60Ysb2bpI/vn+ihtbHUCC/Z5LzzY8CtvC4cqydoVfl4hPxbi+oZaaoBM8Ul9AJ
no9Ql7lK6J5SRuLqs8vB5XAYdt+crm76fzg0kMpNm4zkNNMqOLDIUYy/tLXqibwl
TnGvah9PeN9mxo72iURIhXbnIUeoabShr3ELKSgu22QZ1l7yG3WGhoGMGoOTqIU=
=LaFD
-END PGP SIGNATURE-

Re: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only

[Michał Górny]

Dnia 2014-02-20, o godz. 14:12:17
Lars Wendler  napisał(a):

> So what can we do? Three solutions came to my mind which I list
> here in the order first being my favorite, last being my least
> favorite:
> 
> 1.)
> Make portage's unpack function lzip compatible

Three packages still don't sound like something to add to EAPI. Even
with ten, I would have my doubts. Reading the whole thread, lzip
doesn't seem like it's going to live long. Trying to artificially force
it upon people is only going to give opposite results.

> 2.)
> Fix this on ebuild level:
> - add app-arch/lzip to DEPEND
> - add something like
>   'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die'
>   to a custom src_unpack() function.

Either that, or add it to unpacker.eclass and use it. That's the place
where we handle all the random cruft, and where we can fix it as
problems arise.

> 3.)
> Provide all affected source tarballs ourselves in a portage compatible
> compressed format.

I think that'd be a waste of effort, to be honest. I think using lzip
(and lzip only) is the problem, and we shouldn't bury it like this.

> 4.)
> Try very hard to convince upstream to provide sources in differently
> compressed tarballs.

If you can't convince them yourself, let our users do that. Gentoo is
pretty specific in the way people handle extra dependencies they find
unnecessary :).

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Tom Wijsman]

On Thu, 20 Feb 2014 11:26:18 +0200
Samuli Suominen  wrote:

> 
> On 20/02/14 10:47, Steev Klimaszewski wrote:
> > On Thu, 2014-02-20 at 10:40 +0200, Samuli Suominen wrote:
> >> On 20/02/14 09:44, Steev Klimaszewski wrote:
> >>> On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
>  On 20/02/14 00:23, Ulrich Mueller wrote:
> > Following up to today's QA meeting: The gtk3 USE flag is used by
> > 27 packages, so I suggest making it a global flag:
> >
> > gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version
> > 3
> >
> > Ulrich
>  that would suggest it's fine to use, and is anything but
>  temporary
> 
>  -1 from here
> 
> >>> MATE desktop (which I hope to bring in to Portage soon) can be
> >>> built against gtk+ 2 or gtk+ 3, and upstream supports doing both,
> >>> so +1 from me.  Just because gtk+ 3 is the latest, does not mean
> >>> it's the greatest, and I really wish people would realize that
> >>> newest != bestest.
> >>>
> >>>
> >> Then you pick whatever is best supported for MATE, and ship it
> >> using that. Later when they have completed their support for
> >> GTK+-3, and it's the best supported, you ship that. It's not
> >> rocket science.
> >>
> > OR, since I'm the maintainer, I decide that I'm willing to deal with
> > both, instead of you telling me that I need to pick one or the
> > other. Upstream says both are supported and viable, and I'm willing
> > to deal with the headaches.  Just because you're unwilling doesn't
> > mean others aren't.  kthx.
> >
> >
> 
> Bye bye distribution level consistency :-(
> 
> It's sad that few stubborn developers can do that.
> 
> - Samuli
> 

"'Ey! Have you heard about it. Gentoo doesn't provide X with support
for Y, then what are their USE flags even for; what a shame, ..."

If people want to support and use multiple things, let them do so. It is
pretty much what Gentoo and its philosophy are about; which somewhat
can be summarized as providing choices such that we fit the users'
need, and not force our one true way upon them...

Greetings from someone who runs GNOME 3 and MATE simultaneously; you can
intentionally break it, but why would you? It takes away our happiness.
On the other hand, there's the part where you want to break it for a
reason, perhaps for your happiness; but then I'd like to hear why.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only

[Christoph Junghans]

2014-02-20 8:19 GMT-07:00 Mike Gilbert :
> On Thu, Feb 20, 2014 at 8:12 AM, Lars Wendler  wrote:
>> Hi,
>>
>> it seems like some GNU projects start to release their source tarballs
>> in lzip compressed versions only [1][2].
>> This is a problem since portage's unpack function doesn't know anything
>> about lzip.
>>
>> ...
>>
>> What do you think?
>>
>
> A short-term solution would be to add lzip support to unpacker.eclass
> and utilize that instead of the built-in unpack function.
I had the same idea:


>
> A long-term solution would be to modify PMS to support unpacking lzip 
> archives.
I don't see, why we should do that. unpacker.eclass is a good place to
support exotic archive formats.

>
> Either way, you will still need to have app-arch/lzip in DEPEND,
> similar to app-arch/unzip.
Or use $(unpacker_src_uri_depends).

>



-- 
Christoph Junghans
http://dev.gentoo.org/~ottxor/

Re: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only

[Lars Wendler]

On Thu, 20 Feb 2014 16:28:30 +0100 Ulrich Mueller wrote:

>Last time I checked, lzip compressed slightly worse and was slower
>than xz-utils, so there really is no reason why one would want to use
>it. Maybe more important, even if lzip was at par with xz-utils, the
>latter has won the competition and is vastly more popular.
>
>What was his argument for refusing a release in .tar.xz format?

You can find some of his arguments in https://bugs.gentoo.org/249059

>> So what can we do? Three solutions came to my mind which I list here
>> in the order first being my favorite, last being my least favorite:
>
>> 1.) Make portage's unpack function lzip compatible
>
>> 2.) Fix this on ebuild level: - add app-arch/lzip to DEPEND - add
>> something like 'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die' to a
>> custom src_unpack() function.
>
>> 3.) Provide all affected source tarballs ourselves in a portage
>> compatible compressed format.
>
>> 4.) Try very hard to convince upstream to provide sources in
>> differently compressed tarballs.
>
>It would rate them in order 4, 3, 2, 1, with 4 being my favourite.
>
>Ulrich

Well, 4 is the most uphill of all solutions with little chance of
success. And even if we can convince some upstreams, we'd still have to
deal with the ones refusing our request.
3 is similar annoying as we have to make sure to provide these tarballs
like forever.

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


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Ciaran McCreesh]

On Thu, 20 Feb 2014 11:48:11 +0100
Ulrich Mueller  wrote:
> We don't want users having to solve a Zebra Puzzle [1] (or, for the
> more theoretically inclined, a satisfiability problem [2]) to find
> an acceptable combination of their USE flags.

Actually, REQUIRED_USE was introduced precisely to require users to
solve SAT without help... As you may recall, we *were* going to use
pkg_pretend for this sort of thing to give the users a friendly error
message, but this was replaced at the last minute with REQUIRED_USE to
force package manglers to reduce the quality of error message that's
produced.

So really we should just scrap REQUIRED_USE in EAPI 6, and migrate any
ebuilds currently using it to a sane alternative.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only

[Ulrich Mueller]

> On Thu, 20 Feb 2014, Lars Wendler wrote:

> it seems like some GNU projects start to release their source
> tarballs in lzip compressed versions only [1][2]. This is a problem
> since portage's unpack function doesn't know anything about lzip.
> For sys-fs/ddrescue (where I am the Gentoo package maintainer) I
> simply added "app-arch/lzip" to DEPEND and added an appropriate
> src_unpack() function to the ebuild. That immediately lead to [3]
> where I got the request to get rid of that dependency by either
> convince upstream to release their tarballs in a differently
> compressed format or provide a recompressed source tarball myself.
> My conversation with ddrescue upstream was not successful in the way
> that they were willing to provide their sources in several
> differently compressed tarballs.

> Now sys-apps/ed started the same with version 1.10 [2] and I really
> don't want to repeat the whole stuff from ddrescue again without
> having this discussed here.

All this trouble is due to the author of lzip, Antonio Diaz Diaz, who
is trying to promote his own exotic format. Nobody else seems to use
it.

Last time I checked, lzip compressed slightly worse and was slower
than xz-utils, so there really is no reason why one would want to use
it. Maybe more important, even if lzip was at par with xz-utils, the
latter has won the competition and is vastly more popular.

What was his argument for refusing a release in .tar.xz format?

> So what can we do? Three solutions came to my mind which I list here
> in the order first being my favorite, last being my least favorite:

> 1.) Make portage's unpack function lzip compatible

> 2.) Fix this on ebuild level: - add app-arch/lzip to DEPEND - add
> something like 'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die' to a
> custom src_unpack() function.

> 3.) Provide all affected source tarballs ourselves in a portage
> compatible compressed format.

> 4.) Try very hard to convince upstream to provide sources in
> differently compressed tarballs.

It would rate them in order 4, 3, 2, 1, with 4 being my favourite.

Ulrich


pgpYIcEnBsSTN.pgp
Description: PGP signature

Re: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only

[Mike Gilbert]

On Thu, Feb 20, 2014 at 8:12 AM, Lars Wendler  wrote:
> Hi,
>
> it seems like some GNU projects start to release their source tarballs
> in lzip compressed versions only [1][2].
> This is a problem since portage's unpack function doesn't know anything
> about lzip.
>
> ...
>
> What do you think?
>

A short-term solution would be to add lzip support to unpacker.eclass
and utilize that instead of the built-in unpack function.

A long-term solution would be to modify PMS to support unpacking lzip archives.

Either way, you will still need to have app-arch/lzip in DEPEND,
similar to app-arch/unzip.

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

[Alex Alexander]

On 20 Feb 2014 12:30, "Samuli Suominen"  wrote:
>
>
> On 20/02/14 12:07, Duncan wrote:
> > Samuli Suominen posted on Thu, 20 Feb 2014 07:55:44 +0200 as excerpted:
> >
> >> On 20/02/14 00:23, Ulrich Mueller wrote:
> >>> Following up to today's QA meeting: The gtk3 USE flag is used by 27
> >>> packages, so I suggest making it a global flag:
> >>>
> >>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> >>>
> >>> Ulrich
> >> that would suggest it's fine to use, and is anything but temporary
> >>
> >> -1 from here
> > You must have missed the news implied by that "following up" wording,
> > then.  See the announcement/thread "February 2014 QA policy updates",
> > posted by creffett, just a few minutes before this thread started.
>
> I find it sad the QA team has been taken over by some of the new and
> semi-new
> developers who don't completely understand the implications of this
> decision yet
> since they haven't lived through the older transitions.

Well, I find it sad that Gentoo is trying really hard to resist change -
although things have been improving lately.

Honestly, I really like the new QA team, we actually push things forward!
Sure, not everyone will always agree with us, but that is natural.

By the way, we did not take over. We were entrusted with this role, we
discuss everything with the community and try to take decisions that are
good for Gentoo. We don't have some secret ulterior motive to take over the
world through Gentoo.

For what it's worth, as a QA member I always vote with what I believe is
best for Gentoo in mind.

Cheers,
Alex

[gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only

[Lars Wendler]

Hi,

it seems like some GNU projects start to release their source tarballs
in lzip compressed versions only [1][2].
This is a problem since portage's unpack function doesn't know anything
about lzip.
For sys-fs/ddrescue (where I am the Gentoo package maintainer) I simply
added "app-arch/lzip" to DEPEND and added an appropriate src_unpack()
function to the ebuild. That immediately lead to [3] where I got the
request to get rid of that dependency by either convince upstream to
release their tarballs in a differently compressed format or provide a
recompressed source tarball myself. My conversation with ddrescue
upstream was not successful in the way that they were willing to
provide their sources in several differently compressed tarballs.

Now sys-apps/ed started the same with version 1.10 [2] and I really
don't want to repeat the whole stuff from ddrescue again without having
this discussed here.

So what can we do? Three solutions came to my mind which I list
here in the order first being my favorite, last being my least
favorite:

1.)
Make portage's unpack function lzip compatible

2.)
Fix this on ebuild level:
- add app-arch/lzip to DEPEND
- add something like
  'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die'
  to a custom src_unpack() function.

3.)
Provide all affected source tarballs ourselves in a portage compatible
compressed format.

4.)
Try very hard to convince upstream to provide sources in differently
compressed tarballs.


What do you think?

[1] ftp://ftp.gnu.org/gnu/ddrescue/
[2] ftp://ftp.gnu.org/gnu/ed/
[3] https://bugs.gentoo.org/485462

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


signature.asc
Description: PGP signature

Re: Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

[Matt Turner]

On Thu, Feb 20, 2014 at 4:21 AM, Andreas K. Huettel
 wrote:
>> I find it sad the QA team has been taken over by some of the new and
>> semi-new
>> developers who don't completely understand the implications of this
>> decision yet
>> since they haven't lived through the older transitions.
>
> As far as I can remember, the "experienced" and "older" developers were unable
> to work together in a QA team and actually stick to the policies themselves.

That's not necessarily worse. :)

Re: Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

[Andreas K. Huettel]

> 
> I find it sad the QA team has been taken over by some of the new and
> semi-new
> developers who don't completely understand the implications of this
> decision yet
> since they haven't lived through the older transitions.

As far as I can remember, the "experienced" and "older" developers were unable 
to work together in a QA team and actually stick to the policies themselves.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Ulrich Mueller]

> On Thu, 20 Feb 2014, Alexandre Rostovtsev wrote:

> I see. So you want USE="gtk gtk3" to mean the same thing that gnome
> team had intended USE="gtk" to mean, which is to say, "pick
> whichever gtk version that is the most sensible".

Exactly.

> That could work. There are already a few ebuilds, e.g. audacious,
> with REQUIRED_USE="^^ ( gtk gtk3 )" - so before this unfortunate
> practice spreads further, the gnome team would need to note on the
> wiki to make sure other developers know why this is especially
> undesirable for the gtk/gtk3 flag pair.

Devs should really follow the policy outlined in the devmanual.
REQUIRED_USE was introduced to solve a specific problem with USE
dependencies (which can break if a USE flag is ignored in an ebuild
because it is superseded by another one). It shouldn't be used all
over the place.

We don't want users having to solve a Zebra Puzzle [1] (or, for the
more theoretically inclined, a satisfiability problem [2]) to find
an acceptable combination of their USE flags.

Ulrich

[1] http://en.wikipedia.org/wiki/Zebra_Puzzle
[2] http://en.wikipedia.org/wiki/Boolean_satisfiability_problem


pgpaxf5ffTwfe.pgp
Description: PGP signature

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Lars Wendler]

On Thu, 20 Feb 2014 11:28:36 +0200 Samuli Suominen wrote:

>
>On 20/02/14 11:23, Steev Klimaszewski wrote:
>> On Thu, 2014-02-20 at 03:59 -0500, Alexandre Rostovtsev wrote:
>>> And this is an example of why everyone on the gnome team doesn't
>>> like the "gtk3" flag. Because well-meaning developers will be
>>> looking at their one corner of the portage tree, deciding that they
>>> are going to handle the choice of gtk version without slotting, and
>>> not consider the effect on the distro as a whole.
>>>
>>> You know what's going to happen now, after the QA team decision?
>>>
>>> First of all, lots of developers will start renaming "gtk" to
>>> "gtk3" in their ebuilds' IUSE.
>>>
>>> Which means "gtk gtk3" will soon have to be added to USE in
>>> targets/desktop/gnome/make.defaults (currently, the gnome profile
>>> globally only has USE="gtk" because the "gtk3" flag is evil).
>>>
>>> And users of non-gnome profiles who use gnome applications will of
>>> course manually add "gtk gtk3" to USE in their local make.conf.
>>>
>>> Unfortunately, at the same time, lots of other developers are going
>>> to start adding support for building against gtk2 XOR gtk3. Because
>>> of course "Gentoo is about choice", and the more choices, the
>>> merrier, and the gtk3 flag has been declared as supported by the QA
>>> team. And that means lots of REQUIRED_USE="^^ ( gtk gtk3 )".
>>>
>>> For the gnome team this results in a headache: maintaining a big
>>> list of "-gtk" / "-gtk3" entries in
>>> targets/desktop/gnome/package.use so that gnome users get a
>>> sensible choice and don't need to edit /etc/portage/* just to
>>> emerge widely used desktop tools.
>>>
>>> But for non-gnome users who manually added USE=gtk3 to make.conf,
>>> this means regular emerge conflicts after sync, forcing them to
>>> *guess* whether "-gtk" or "-gtk3" in pacakge.use is the better
>>> choice. Maybe with portage auto-suggesting the wrong solution just
>>> to add to the wonderful user experience :/
>>>
>> See, now this is an example of a good email as to why supporting both
>> can be a hassle for more than just one desktop.  Instead of telling
>> me that I'm dumb for thinking it's a good idea to follow upstream's
>> supported ideas, and that we should force one or the other.
>>
>> The KDE team seems to be able to deal with it just fine, but somehow
>> it's impossible and hard for the GNOME team.  Why is that?  What does
>> KDE do differently that makes it feasible?
>>
>>
>
>No, they didn't manage it, at all, which why we don't see Qt3/KDE3 in
>tree anymore.
>

Very bad excuse... They punted kde3 because they didn't have the
manpower to stem both KDEs...

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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

[Samuli Suominen]

On 20/02/14 12:07, Duncan wrote:
> Samuli Suominen posted on Thu, 20 Feb 2014 07:55:44 +0200 as excerpted:
>
>> On 20/02/14 00:23, Ulrich Mueller wrote:
>>> Following up to today's QA meeting: The gtk3 USE flag is used by 27
>>> packages, so I suggest making it a global flag:
>>>
>>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
>>>
>>> Ulrich
>> that would suggest it's fine to use, and is anything but temporary
>>
>> -1 from here
> You must have missed the news implied by that "following up" wording, 
> then.  See the announcement/thread "February 2014 QA policy updates", 
> posted by creffett, just a few minutes before this thread started.

I find it sad the QA team has been taken over by some of the new and
semi-new
developers who don't completely understand the implications of this
decision yet
since they haven't lived through the older transitions.

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Alexandre Rostovtsev]

On Thu, 2014-02-20 at 10:26 +0100, Ulrich Mueller wrote:
> > On Thu, 20 Feb 2014, Alexandre Rostovtsev wrote:
> 
> > Unfortunately, at the same time, lots of other developers are going
> > to start adding support for building against gtk2 XOR gtk3. Because
> > of course "Gentoo is about choice", and the more choices, the
> > merrier, and the gtk3 flag has been declared as supported by the QA
> > team. And that means lots of REQUIRED_USE="^^ ( gtk gtk3 )".
> 
> No, in most cases REQUIRED_USE would be against policy. The actual
> policy is to "pick one of the USE flags in conflict to favour and
> should alert the user that a particular flag is being used instead",
> see the devmanual:
> http://devmanual.gentoo.org/general-concepts/use-flags/index.html
> 
> > For the gnome team this results in a headache: maintaining a big
> > list of "-gtk" / "-gtk3" entries in
> > targets/desktop/gnome/package.use so that gnome users get a sensible
> > choice and don't need to edit /etc/portage/* just to emerge widely
> > used desktop tools.
> 
> Right, and that's exactly the reason why REQUIRED_USE should not be
> used, except where it's forced be reverse USE dependencies. Quoting
> the devmanual again:
> "Note: In order to avoid forcing users to micro-manage flags too much,
> REQUIRED_USE should be used sparingly. Follow the normal policy
> whenever it is possible to do a build that will presumably suit the
> user's needs."
> 
> Ulrich

I see. So you want USE="gtk gtk3" to mean the same thing that gnome team
had intended USE="gtk" to mean, which is to say, "pick whichever gtk
version that is the most sensible".

That could work. There are already a few ebuilds, e.g. audacious, with
REQUIRED_USE="^^ ( gtk gtk3 )" - so before this unfortunate practice
spreads further, the gnome team would need to note on the wiki to make
sure other developers know why this is especially undesirable for the
gtk/gtk3 flag pair.

The other unfortunate aspect of the gtk3 flag is that it encourages
using flags instead of slotting for libraries that can support both gtk
and gtk3, resulting in needless rebuilds of when one of the flags is
switched on/off. But again, that could be addressed with a bit of
documentation.


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: RFD: new global USE flag gtk3

[Duncan]

Samuli Suominen posted on Thu, 20 Feb 2014 07:55:44 +0200 as excerpted:

> On 20/02/14 00:23, Ulrich Mueller wrote:
>> Following up to today's QA meeting: The gtk3 USE flag is used by 27
>> packages, so I suggest making it a global flag:
>>
>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
>>
>> Ulrich
> 
> that would suggest it's fine to use, and is anything but temporary
> 
> -1 from here

You must have missed the news implied by that "following up" wording, 
then.  See the announcement/thread "February 2014 QA policy updates", 
posted by creffett, just a few minutes before this thread started.

http://permalink.gmane.org/gmane.linux.gentoo.devel/90291


Thus indeed, "anything but temporary" it appears to be.

(Personally, FWIW, while I understood the previous policy and wasn't 
complaining, as a user who doesn't yet have gtk3 installed and who hopes 
to convert all my installed gtk dependers to gtk3 at once and kill gtk2 
at the same time I install gtk3 when the time comes, I do appreciate the 
new policy, as it'll be that much easier to track what's pulling in one 
or the other during the transition period.)

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

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Alex Alexander]

On 20 Feb 2014 10:12, "Michał Górny"  wrote:
>
> Dnia 2014-02-20, o godz. 01:44:17
> Steev Klimaszewski  napisał(a):
>
> > On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
> > > On 20/02/14 00:23, Ulrich Mueller wrote:
> > > > Following up to today's QA meeting: The gtk3 USE flag is used by
> > > > 27 packages, so I suggest making it a global flag:
> > > >
> > > > gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> > > >
> > > > Ulrich
> > >
> > > that would suggest it's fine to use, and is anything but temporary
> > >
> > > -1 from here
> > >
> > MATE desktop (which I hope to bring in to Portage soon) can be built
> > against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
> > me.
>
> Except that now users have to use USE='gtk gtk3' to get GUIs in random
> applications that support only one toolkit. And then handle
> REQUIRED_USE mess for packages that support choosing one of the two.
>
> > Just because gtk+ 3 is the latest, does not mean it's the greatest,
> > and I really wish people would realize that newest != bestest.
>
> Yet it's supported, unlike GTK+2. I really wish people would actually
> step up to fix bugs when the time comes rather than shouting about their
> right to choose.

The main idea here is to create a system that is consistent.

Yes, gtk2 is still used and IMO we need to provide support for it as long
as there are apps linked to it with no real alternatives.

But we also need to think about the future. The situation today is a total
mess.

In an ideal world, gtk3 would replace gtk2 everywhere in an instant, making
this discussion pointless. Unfortunately, this is not the case.

Versioned USE flags solve most of the problems with minimum fuss, while
paving the road for a much cleaner gtk3 -> gtk4 transition.

We don't really need generic use flags anyway. Adding gtk3 to your USE is
really easy and I expect our user base to be able to handle these things
with ease.

Alex

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Alexandre Rostovtsev]

On Thu, 2014-02-20 at 03:23 -0600, Steev Klimaszewski wrote:
> The KDE team seems to be able to deal with it just fine, but somehow
> it's impossible and hard for the GNOME team.  Why is that?  What does
> KDE do differently that makes it feasible?

The KDE ecosystem moved from qt3 to qt4 around 2007-2009, when Gentoo
was at EAPI1 and EAPI2 (so no REQUIRED_USE), plus it happened so long
ago that any pain from the transition period has been forgotten :)


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Samuli Suominen]

On 20/02/14 11:23, Steev Klimaszewski wrote:
> On Thu, 2014-02-20 at 03:59 -0500, Alexandre Rostovtsev wrote:
>> And this is an example of why everyone on the gnome team doesn't like
>> the "gtk3" flag. Because well-meaning developers will be looking at
>> their one corner of the portage tree, deciding that they are going to
>> handle the choice of gtk version without slotting, and not consider the
>> effect on the distro as a whole.
>>
>> You know what's going to happen now, after the QA team decision?
>>
>> First of all, lots of developers will start renaming "gtk" to "gtk3" in
>> their ebuilds' IUSE.
>>
>> Which means "gtk gtk3" will soon have to be added to USE in
>> targets/desktop/gnome/make.defaults (currently, the gnome profile
>> globally only has USE="gtk" because the "gtk3" flag is evil).
>>
>> And users of non-gnome profiles who use gnome applications will of
>> course manually add "gtk gtk3" to USE in their local make.conf.
>>
>> Unfortunately, at the same time, lots of other developers are going to
>> start adding support for building against gtk2 XOR gtk3. Because of
>> course "Gentoo is about choice", and the more choices, the merrier, and
>> the gtk3 flag has been declared as supported by the QA team. And that
>> means lots of REQUIRED_USE="^^ ( gtk gtk3 )".
>>
>> For the gnome team this results in a headache: maintaining a big list of
>> "-gtk" / "-gtk3" entries in targets/desktop/gnome/package.use so that
>> gnome users get a sensible choice and don't need to edit /etc/portage/*
>> just to emerge widely used desktop tools.
>>
>> But for non-gnome users who manually added USE=gtk3 to make.conf, this
>> means regular emerge conflicts after sync, forcing them to *guess*
>> whether "-gtk" or "-gtk3" in pacakge.use is the better choice. Maybe
>> with portage auto-suggesting the wrong solution just to add to the
>> wonderful user experience :/
>>
> See, now this is an example of a good email as to why supporting both
> can be a hassle for more than just one desktop.  Instead of telling me
> that I'm dumb for thinking it's a good idea to follow upstream's
> supported ideas, and that we should force one or the other.
>
> The KDE team seems to be able to deal with it just fine, but somehow
> it's impossible and hard for the GNOME team.  Why is that?  What does
> KDE do differently that makes it feasible?
>
>

No, they didn't manage it, at all, which why we don't see Qt3/KDE3 in
tree anymore.

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Samuli Suominen]

On 20/02/14 10:47, Steev Klimaszewski wrote:
> On Thu, 2014-02-20 at 10:40 +0200, Samuli Suominen wrote:
>> On 20/02/14 09:44, Steev Klimaszewski wrote:
>>> On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
 On 20/02/14 00:23, Ulrich Mueller wrote:
> Following up to today's QA meeting: The gtk3 USE flag is used by
> 27 packages, so I suggest making it a global flag:
>
> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
>
> Ulrich
 that would suggest it's fine to use, and is anything but temporary

 -1 from here

>>> MATE desktop (which I hope to bring in to Portage soon) can be built
>>> against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
>>> me.  Just because gtk+ 3 is the latest, does not mean it's the greatest,
>>> and I really wish people would realize that newest != bestest.
>>>
>>>
>> Then you pick whatever is best supported for MATE, and ship it using that.
>> Later when they have completed their support for GTK+-3, and it's the
>> best supported, you ship that. It's not rocket science.
>>
> OR, since I'm the maintainer, I decide that I'm willing to deal with
> both, instead of you telling me that I need to pick one or the other.
> Upstream says both are supported and viable, and I'm willing to deal
> with the headaches.  Just because you're unwilling doesn't mean others
> aren't.  kthx.
>
>

Bye bye distribution level consistency :-(

It's sad that few stubborn developers can do that.

- Samuli

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Ulrich Mueller]

> On Thu, 20 Feb 2014, Alexandre Rostovtsev wrote:

> Unfortunately, at the same time, lots of other developers are going
> to start adding support for building against gtk2 XOR gtk3. Because
> of course "Gentoo is about choice", and the more choices, the
> merrier, and the gtk3 flag has been declared as supported by the QA
> team. And that means lots of REQUIRED_USE="^^ ( gtk gtk3 )".

No, in most cases REQUIRED_USE would be against policy. The actual
policy is to "pick one of the USE flags in conflict to favour and
should alert the user that a particular flag is being used instead",
see the devmanual:
http://devmanual.gentoo.org/general-concepts/use-flags/index.html

> For the gnome team this results in a headache: maintaining a big
> list of "-gtk" / "-gtk3" entries in
> targets/desktop/gnome/package.use so that gnome users get a sensible
> choice and don't need to edit /etc/portage/* just to emerge widely
> used desktop tools.

Right, and that's exactly the reason why REQUIRED_USE should not be
used, except where it's forced be reverse USE dependencies. Quoting
the devmanual again:
"Note: In order to avoid forcing users to micro-manage flags too much,
REQUIRED_USE should be used sparingly. Follow the normal policy
whenever it is possible to do a build that will presumably suit the
user's needs."

Ulrich


pgpaoSr1YvHDx.pgp
Description: PGP signature

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Steev Klimaszewski]

On Thu, 2014-02-20 at 03:59 -0500, Alexandre Rostovtsev wrote:
> And this is an example of why everyone on the gnome team doesn't like
> the "gtk3" flag. Because well-meaning developers will be looking at
> their one corner of the portage tree, deciding that they are going to
> handle the choice of gtk version without slotting, and not consider the
> effect on the distro as a whole.
> 
> You know what's going to happen now, after the QA team decision?
> 
> First of all, lots of developers will start renaming "gtk" to "gtk3" in
> their ebuilds' IUSE.
> 
> Which means "gtk gtk3" will soon have to be added to USE in
> targets/desktop/gnome/make.defaults (currently, the gnome profile
> globally only has USE="gtk" because the "gtk3" flag is evil).
> 
> And users of non-gnome profiles who use gnome applications will of
> course manually add "gtk gtk3" to USE in their local make.conf.
> 
> Unfortunately, at the same time, lots of other developers are going to
> start adding support for building against gtk2 XOR gtk3. Because of
> course "Gentoo is about choice", and the more choices, the merrier, and
> the gtk3 flag has been declared as supported by the QA team. And that
> means lots of REQUIRED_USE="^^ ( gtk gtk3 )".
> 
> For the gnome team this results in a headache: maintaining a big list of
> "-gtk" / "-gtk3" entries in targets/desktop/gnome/package.use so that
> gnome users get a sensible choice and don't need to edit /etc/portage/*
> just to emerge widely used desktop tools.
> 
> But for non-gnome users who manually added USE=gtk3 to make.conf, this
> means regular emerge conflicts after sync, forcing them to *guess*
> whether "-gtk" or "-gtk3" in pacakge.use is the better choice. Maybe
> with portage auto-suggesting the wrong solution just to add to the
> wonderful user experience :/
> 
See, now this is an example of a good email as to why supporting both
can be a hassle for more than just one desktop.  Instead of telling me
that I'm dumb for thinking it's a good idea to follow upstream's
supported ideas, and that we should force one or the other.

The KDE team seems to be able to deal with it just fine, but somehow
it's impossible and hard for the GNOME team.  Why is that?  What does
KDE do differently that makes it feasible?

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Alexandre Rostovtsev]

On Thu, 2014-02-20 at 02:47 -0600, Steev Klimaszewski wrote:
> OR, since I'm the maintainer, I decide that I'm willing to deal with
> both, instead of you telling me that I need to pick one or the other.
> Upstream says both are supported and viable, and I'm willing to deal
> with the headaches.  Just because you're unwilling doesn't mean others
> aren't.  kthx.

And this is an example of why everyone on the gnome team doesn't like
the "gtk3" flag. Because well-meaning developers will be looking at
their one corner of the portage tree, deciding that they are going to
handle the choice of gtk version without slotting, and not consider the
effect on the distro as a whole.

You know what's going to happen now, after the QA team decision?

First of all, lots of developers will start renaming "gtk" to "gtk3" in
their ebuilds' IUSE.

Which means "gtk gtk3" will soon have to be added to USE in
targets/desktop/gnome/make.defaults (currently, the gnome profile
globally only has USE="gtk" because the "gtk3" flag is evil).

And users of non-gnome profiles who use gnome applications will of
course manually add "gtk gtk3" to USE in their local make.conf.

Unfortunately, at the same time, lots of other developers are going to
start adding support for building against gtk2 XOR gtk3. Because of
course "Gentoo is about choice", and the more choices, the merrier, and
the gtk3 flag has been declared as supported by the QA team. And that
means lots of REQUIRED_USE="^^ ( gtk gtk3 )".

For the gnome team this results in a headache: maintaining a big list of
"-gtk" / "-gtk3" entries in targets/desktop/gnome/package.use so that
gnome users get a sensible choice and don't need to edit /etc/portage/*
just to emerge widely used desktop tools.

But for non-gnome users who manually added USE=gtk3 to make.conf, this
means regular emerge conflicts after sync, forcing them to *guess*
whether "-gtk" or "-gtk3" in pacakge.use is the better choice. Maybe
with portage auto-suggesting the wrong solution just to add to the
wonderful user experience :/



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Steev Klimaszewski]

On Thu, 2014-02-20 at 09:11 +0100, Michał Górny wrote:
> Dnia 2014-02-20, o godz. 01:44:17
> Steev Klimaszewski  napisał(a):
> 
> > On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
> > > On 20/02/14 00:23, Ulrich Mueller wrote:
> > > > Following up to today's QA meeting: The gtk3 USE flag is used by
> > > > 27 packages, so I suggest making it a global flag:
> > > >
> > > > gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> > > >
> > > > Ulrich
> > > 
> > > that would suggest it's fine to use, and is anything but temporary
> > > 
> > > -1 from here
> > > 
> > MATE desktop (which I hope to bring in to Portage soon) can be built
> > against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
> > me.
> 
> Except that now users have to use USE='gtk gtk3' to get GUIs in random
> applications that support only one toolkit. And then handle
> REQUIRED_USE mess for packages that support choosing one of the two.
> 

Sorry?  Still better than forcing things on because it allows me to be
lazy.  

> > Just because gtk+ 3 is the latest, does not mean it's the greatest,
> > and I really wish people would realize that newest != bestest.
> 
> Yet it's supported, unlike GTK+2. I really wish people would actually
> step up to fix bugs when the time comes rather than shouting about their
> right to choose.
> 
Who is shouting about right to choose?  In fact, I see only MATE in
capital letters there, and that's because that's the way that it's
written by upstream.  Just because you enjoy forcing people to do things
your way, doesn't mean everyone feels the need to be controlling.  I'm
cool with giving the users choice, it doesn't HAVE to be done, but I'm
not so against it that I insist they follow my one true way...

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Ulrich Mueller]

> On Thu, 20 Feb 2014, Michał Górny wrote:

> Except that now users have to use USE='gtk gtk3' to get GUIs in
> random applications that support only one toolkit. And then handle
> REQUIRED_USE mess for packages that support choosing one of the two.

Why REQUIRED_USE? A package can prefer one of the alternatives if both
flags are specified. Probably it's a good idea to emit a warning,
though.

Ulrich


pgpJuT3ABBNMC.pgp
Description: PGP signature

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Steev Klimaszewski]

On Thu, 2014-02-20 at 10:40 +0200, Samuli Suominen wrote:
> On 20/02/14 09:44, Steev Klimaszewski wrote:
> > On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
> >> On 20/02/14 00:23, Ulrich Mueller wrote:
> >>> Following up to today's QA meeting: The gtk3 USE flag is used by
> >>> 27 packages, so I suggest making it a global flag:
> >>>
> >>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> >>>
> >>> Ulrich
> >> that would suggest it's fine to use, and is anything but temporary
> >>
> >> -1 from here
> >>
> > MATE desktop (which I hope to bring in to Portage soon) can be built
> > against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
> > me.  Just because gtk+ 3 is the latest, does not mean it's the greatest,
> > and I really wish people would realize that newest != bestest.
> >
> >
> 
> Then you pick whatever is best supported for MATE, and ship it using that.
> Later when they have completed their support for GTK+-3, and it's the
> best supported, you ship that. It's not rocket science.
> 

OR, since I'm the maintainer, I decide that I'm willing to deal with
both, instead of you telling me that I need to pick one or the other.
Upstream says both are supported and viable, and I'm willing to deal
with the headaches.  Just because you're unwilling doesn't mean others
aren't.  kthx.

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Samuli Suominen]

On 20/02/14 09:44, Steev Klimaszewski wrote:
> On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
>> On 20/02/14 00:23, Ulrich Mueller wrote:
>>> Following up to today's QA meeting: The gtk3 USE flag is used by
>>> 27 packages, so I suggest making it a global flag:
>>>
>>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
>>>
>>> Ulrich
>> that would suggest it's fine to use, and is anything but temporary
>>
>> -1 from here
>>
> MATE desktop (which I hope to bring in to Portage soon) can be built
> against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
> me.  Just because gtk+ 3 is the latest, does not mean it's the greatest,
> and I really wish people would realize that newest != bestest.
>
>

Then you pick whatever is best supported for MATE, and ship it using that.
Later when they have completed their support for GTK+-3, and it's the
best supported, you ship that. It's not rocket science.

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Lars Wendler]

On Wed, 19 Feb 2014 23:23:23 +0100 Ulrich Mueller wrote:

>Following up to today's QA meeting: The gtk3 USE flag is used by
>27 packages, so I suggest making it a global flag:
>
>gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
>
>Ulrich

+1 

gtk+:3 still is a mess even in its tenth incarnation...

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


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Michał Górny]

Dnia 2014-02-20, o godz. 01:44:17
Steev Klimaszewski  napisał(a):

> On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
> > On 20/02/14 00:23, Ulrich Mueller wrote:
> > > Following up to today's QA meeting: The gtk3 USE flag is used by
> > > 27 packages, so I suggest making it a global flag:
> > >
> > > gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> > >
> > > Ulrich
> > 
> > that would suggest it's fine to use, and is anything but temporary
> > 
> > -1 from here
> > 
> MATE desktop (which I hope to bring in to Portage soon) can be built
> against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
> me.

Except that now users have to use USE='gtk gtk3' to get GUIs in random
applications that support only one toolkit. And then handle
REQUIRED_USE mess for packages that support choosing one of the two.

> Just because gtk+ 3 is the latest, does not mean it's the greatest,
> and I really wish people would realize that newest != bestest.

Yet it's supported, unlike GTK+2. I really wish people would actually
step up to fix bugs when the time comes rather than shouting about their
right to choose.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature