Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Fwd: Heads up for Qt5

 

 

Gentoo dev RSS feed   Index | Next | Previous | View Threaded


yngwin at gentoo

Jul 27, 2012, 10:22 PM

Post #1 of 11 (1285 views)
Permalink
Fwd: Heads up for Qt5

Hi!

We are getting nearer to a Qt5 beta release. Although it has already
been postponed a couple of times, we should expect it some time this
summer. This means we will start to see packages offering Qt5 support.

Pesa has already done a terrific job preparing live ebuilds and
eclasses for building Qt5 (tho maybe not all modules may be ready at
this point). They are available in our overlay. This should be a good
starting point for eventual release ebuilds that will hit the official
tree later.

In preparation for that, we want to ask maintainers of all ebuilds in
the tree with dependencies on Qt4, to make sure that they have the
proper slot. Otherwise your package may pull in Qt5 while it may not
in fact support it. Kensington has already done a good job, and is
presently being assisted by johu, going thru the tree, hunting for
such ebuilds. So you may get pinged about this issue if one of your
packages is affected.

We ourselves have made this oversight in the past in qt4-build.eclass,
which used to have unslotted blockers. This means that Qt5 was
actually blocked as well. Pesa fixed this a while ago, but people will
continue to have the unslotted blockers stored in their vdb until they
re-emerge or update all qt4 packages. Our apologies for the
inconvenience...

I also want to notify you that we will be using the "qt4" and "qt5"
useflags to indicate optional support for the respective Qt versions.

And finally, I want to thank all my fellow Qt team devs for making it
such a pleasure to work together on improving users' experience of Qt
libs and apps.
--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin


realnc at gmail

Jul 27, 2012, 10:59 PM

Post #2 of 11 (1251 views)
Permalink
Re: Fwd: Heads up for Qt5 [In reply to]

On 28/07/12 08:22, Ben de Groot wrote:
> In preparation for that, we want to ask maintainers of all ebuilds in
> the tree with dependencies on Qt4, to make sure that they have the
> proper slot. Otherwise your package may pull in Qt5 while it may not
> in fact support it.

This can be trouble if the application actually works with Qt5. It
might depend on Qt4 but has no problems with Qt5 (contrary to Qt3 vs
Qt4, Qt5 is mostly compatible with much of existing Qt4 code),
needlessly pulling-in Qt4. Many applications simply build and run as-is
and no code changes are necessary.

So what would be the methodology of making sure a package has the proper
slot?


yngwin at gentoo

Jul 27, 2012, 11:27 PM

Post #3 of 11 (1250 views)
Permalink
Re: Re: Fwd: Heads up for Qt5 [In reply to]

On 28 July 2012 13:59, Nikos Chantziaras <realnc [at] gmail> wrote:
> On 28/07/12 08:22, Ben de Groot wrote:
>>
>> In preparation for that, we want to ask maintainers of all ebuilds in
>> the tree with dependencies on Qt4, to make sure that they have the
>> proper slot. Otherwise your package may pull in Qt5 while it may not
>> in fact support it.
>
>
> This can be trouble if the application actually works with Qt5. It might
> depend on Qt4 but has no problems with Qt5 (contrary to Qt3 vs Qt4, Qt5 is
> mostly compatible with much of existing Qt4 code), needlessly pulling-in
> Qt4. Many applications simply build and run as-is and no code changes are
> necessary.
>
> So what would be the methodology of making sure a package has the proper
> slot?

Obviously you would need to make sure that the package actually does
support Qt5. Then, as I see it, we could do either:

|| ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )

or:

qt4? ( x11-libs/qt-gui:4 )
qt5? ( x11-libs/qt-gui:5 )

Other thoughts?
--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin


pesa at gentoo

Jul 27, 2012, 11:46 PM

Post #4 of 11 (1252 views)
Permalink
Re: Re: Fwd: Heads up for Qt5 [In reply to]

On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot <yngwin [at] gentoo> wrote:
> On 28 July 2012 13:59, Nikos Chantziaras <realnc [at] gmail> wrote:
>> On 28/07/12 08:22, Ben de Groot wrote:
>>>
>>> In preparation for that, we want to ask maintainers of all ebuilds in
>>> the tree with dependencies on Qt4, to make sure that they have the
>>> proper slot. Otherwise your package may pull in Qt5 while it may not
>>> in fact support it.
>>
>>
>> This can be trouble if the application actually works with Qt5. It might
>> depend on Qt4 but has no problems with Qt5 (contrary to Qt3 vs Qt4, Qt5 is
>> mostly compatible with much of existing Qt4 code), needlessly pulling-in
>> Qt4. Many applications simply build and run as-is and no code changes are
>> necessary.
>>
>> So what would be the methodology of making sure a package has the proper
>> slot?
>
> Obviously you would need to make sure that the package actually does
> support Qt5. Then, as I see it, we could do either:
>
> || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )
>

This is wrong because qt4 and qt5 are not binary compatible.

> or:
>
> qt4? ( x11-libs/qt-gui:4 )
> qt5? ( x11-libs/qt-gui:5 )
>

This is the only alternative AFAICS.

Thanks,
Pesa


realnc at gmail

Jul 27, 2012, 11:56 PM

Post #5 of 11 (1249 views)
Permalink
Re: Fwd: Heads up for Qt5 [In reply to]

On 28/07/12 09:46, Davide Pesavento wrote:
> On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot <yngwin [at] gentoo> wrote:
>> On 28 July 2012 13:59, Nikos Chantziaras <realnc [at] gmail> wrote:
>>> [...]
>>> So what would be the methodology of making sure a package has the proper
>>> slot?
>>
>> Obviously you would need to make sure that the package actually does
>> support Qt5. Then, as I see it, we could do either:
>>
>> || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )
>>
>
> This is wrong because qt4 and qt5 are not binary compatible.
>
>> or:
>>
>> qt4? ( x11-libs/qt-gui:4 )
>> qt5? ( x11-libs/qt-gui:5 )
>>
>
> This is the only alternative AFAICS.

In that case, if Qt5 is installed, the application might depend on Qt4,
but when building it, might link against Qt5.


pesa at gentoo

Jul 28, 2012, 12:09 AM

Post #6 of 11 (1251 views)
Permalink
Re: Re: Fwd: Heads up for Qt5 [In reply to]

On Fri, Jul 27, 2012 at 11:56 PM, Nikos Chantziaras <realnc [at] gmail> wrote:
> On 28/07/12 09:46, Davide Pesavento wrote:
>>
>> On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot <yngwin [at] gentoo> wrote:
>>>
>>> On 28 July 2012 13:59, Nikos Chantziaras <realnc [at] gmail> wrote:
>>>>
>>>> [...]
>>>>
>>>> So what would be the methodology of making sure a package has the proper
>>>> slot?
>>>
>>>
>>> Obviously you would need to make sure that the package actually does
>>> support Qt5. Then, as I see it, we could do either:
>>>
>>> || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )
>>>
>>
>> This is wrong because qt4 and qt5 are not binary compatible.
>>
>>> or:
>>>
>>> qt4? ( x11-libs/qt-gui:4 )
>>> qt5? ( x11-libs/qt-gui:5 )
>>>
>>
>> This is the only alternative AFAICS.
>
>
> In that case, if Qt5 is installed, the application might depend on Qt4, but
> when building it, might link against Qt5.
>
>

No, that would be a bug in the ebuild or somewhere else.

BTW, I'm planning to write a qt5-utils.eclass, which will provide an
eqmake5 function similar to eqmake4 in qt4-r2.eclass.

Cheers,
Pesa


sera at gentoo

Jul 28, 2012, 12:43 AM

Post #7 of 11 (1242 views)
Permalink
Re: Re: Fwd: Heads up for Qt5 [In reply to]

On Sat, 28 Jul 2012 14:27:49 +0800
Ben de Groot <yngwin [at] gentoo> wrote:

> On 28 July 2012 13:59, Nikos Chantziaras <realnc [at] gmail> wrote:
> > On 28/07/12 08:22, Ben de Groot wrote:
> >>
> >> In preparation for that, we want to ask maintainers of all ebuilds
> >> in the tree with dependencies on Qt4, to make sure that they have
> >> the proper slot. Otherwise your package may pull in Qt5 while it
> >> may not in fact support it.
> >
> >
> > This can be trouble if the application actually works with Qt5. It
> > might depend on Qt4 but has no problems with Qt5 (contrary to Qt3
> > vs Qt4, Qt5 is mostly compatible with much of existing Qt4 code),
> > needlessly pulling-in Qt4. Many applications simply build and run
> > as-is and no code changes are necessary.
> >
> > So what would be the methodology of making sure a package has the
> > proper slot?
>
> Obviously you would need to make sure that the package actually does
> support Qt5. Then, as I see it, we could do either:
>
> || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )

Never prefer an old version in an || ( ) block, this makes for a poor
update experience. Also the || ( ) construct can only be used if they
are runtime switchable, which I really doubt here, as otherwise you
build against one, the user install the other and portage depcleans the
one you have built against.

>
> or:
>
> qt4? ( x11-libs/qt-gui:4 )
> qt5? ( x11-libs/qt-gui:5 )
>

A qt5 useflag will do more harm than good. If I enable qt, I do not
care which version, I just want the gui for the particular app. If the
app works with qt:5 the usflag qt means qt:5, if it only works with
qt:4 the useflags means qt:4. In case it works with both and the
maintainer thinks it's worth to let the user choose, use the useflag qt4
to let the user opt out of the latest and greatest.

> Other thoughts?


yngwin at gentoo

Jul 28, 2012, 12:54 AM

Post #8 of 11 (1248 views)
Permalink
Re: Re: Fwd: Heads up for Qt5 [In reply to]

On 28 July 2012 15:43, Ralph Sennhauser <sera [at] gentoo> wrote:
> On Sat, 28 Jul 2012 14:27:49 +0800
> Ben de Groot <yngwin [at] gentoo> wrote:
>
>> On 28 July 2012 13:59, Nikos Chantziaras <realnc [at] gmail> wrote:
>> > On 28/07/12 08:22, Ben de Groot wrote:
>> >>
>> >> In preparation for that, we want to ask maintainers of all ebuilds
>> >> in the tree with dependencies on Qt4, to make sure that they have
>> >> the proper slot. Otherwise your package may pull in Qt5 while it
>> >> may not in fact support it.
>> >
>> >
>> > This can be trouble if the application actually works with Qt5. It
>> > might depend on Qt4 but has no problems with Qt5 (contrary to Qt3
>> > vs Qt4, Qt5 is mostly compatible with much of existing Qt4 code),
>> > needlessly pulling-in Qt4. Many applications simply build and run
>> > as-is and no code changes are necessary.
>> >
>> > So what would be the methodology of making sure a package has the
>> > proper slot?
>>
>> Obviously you would need to make sure that the package actually does
>> support Qt5. Then, as I see it, we could do either:
>>
>> || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )
>
> Never prefer an old version in an || ( ) block, this makes for a poor
> update experience. Also the || ( ) construct can only be used if they
> are runtime switchable, which I really doubt here, as otherwise you
> build against one, the user install the other and portage depcleans the
> one you have built against.

Yes, that was a brainfart. Davide already said it was wrong.

>>
>> or:
>>
>> qt4? ( x11-libs/qt-gui:4 )
>> qt5? ( x11-libs/qt-gui:5 )
>>
>
> A qt5 useflag will do more harm than good. If I enable qt, I do not
> care which version, I just want the gui for the particular app. If the
> app works with qt:5 the usflag qt means qt:5, if it only works with
> qt:4 the useflags means qt:4. In case it works with both and the
> maintainer thinks it's worth to let the user choose, use the useflag qt4
> to let the user opt out of the latest and greatest.

We do not have (nor want to support) a qt useflag. We have opted
for "qt4" and "qt5" useflags as the most straightforward and least
confusing.

It is up to package maintainers if they want to offer to build both
versions where applicable, or prefer one over the other if both
useflags are set.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin


sera at gentoo

Jul 28, 2012, 2:27 AM

Post #9 of 11 (1234 views)
Permalink
Re: Re: Fwd: Heads up for Qt5 [In reply to]

On Sat, 28 Jul 2012 15:54:07 +0800
Ben de Groot <yngwin [at] gentoo> wrote:

> We do not have (nor want to support) a qt useflag. We have opted
> for "qt4" and "qt5" useflags as the most straightforward and least
> confusing.

Indeed, the flag qt has almost disappeared from the tree. Good to know.


realnc at gmail

Jul 28, 2012, 3:07 AM

Post #10 of 11 (1233 views)
Permalink
Re: Fwd: Heads up for Qt5 [In reply to]

On 28/07/12 12:27, Ralph Sennhauser wrote:
> On Sat, 28 Jul 2012 15:54:07 +0800
> Ben de Groot <yngwin [at] gentoo> wrote:
>
>> We do not have (nor want to support) a qt useflag. We have opted
>> for "qt4" and "qt5" useflags as the most straightforward and least
>> confusing.
>
> Indeed, the flag qt has almost disappeared from the tree. Good to know.

Why the different policies between the gtk and qt USE flags? This just
looks inconsistent.


1i5t5.duncan at cox

Jul 28, 2012, 6:57 AM

Post #11 of 11 (1263 views)
Permalink
Re: Fwd: Heads up for Qt5 [In reply to]

Nikos Chantziaras posted on Sat, 28 Jul 2012 13:07:08 +0300 as excerpted:

> On 28/07/12 12:27, Ralph Sennhauser wrote:
>> On Sat, 28 Jul 2012 15:54:07 +0800 Ben de Groot <yngwin [at] gentoo>
>> wrote:
>>
>>> We do not have (nor want to support) a qt useflag. We have opted for
>>> "qt4" and "qt5" useflags as the most straightforward and least
>>> confusing.
>>
>> Indeed, the flag qt has almost disappeared from the tree. Good to know.
>
> Why the different policies between the gtk and qt USE flags? This just
> looks inconsistent.

Different gentoo projects. Different people involved with their own
preferences. But I believe it's mostly an accident of history.

The gtk/gtk2 evolution went rather poorly as IIRC there really wasn't an
original defined policy, so the gtk USE flags were ambiguous. At first
USE=gtk2 was discouraged for a lot of packages, since for them it meant
favoring the still (at the time) less stable gtk2 over gtk1. USE=gtk
meanwhile, sometimes meant favor gtk1, while at other times it meant let
the package maintainer pick the best one to support. Of course that
caused problems later on, after gtk2 matured and gtk1 was being phased
out, so a general policy was adopted, that AFAIK remains today: USE=gtk
meant support gtk in any form, with USE=gtk1/gtk2 (and now gtk3, with
gtk1 phased out) meant prefer that specific version instead of letting
the package maintainer choose a default.

But the key point there is that said policy was kind of fallen into by
accident, and once in place, it was simply more convenient to maintain
it, then to change it yet again.

When the qt3/qt4 case came along, they had the lessons of the gtk case to
examine and decided to avoid the problem by switching to specific-
versioned qtX flags I believe before/as qt4 hit the tree. Of course the
fact that the existing in-tree support was already qt3 helped, since that
was already more intuitive than gtk1. From quite early on, then, simple
qt was never allowed the ambiguity of gtk -- it always meant qt3 but was
quickly deprecated in favor of the qt3 flag.

Of course also helping things was the fact that the qt3 ecosystem was
much more monolithic and kde3 much more dominant within it than was the
case with either gtk1/gnome1 or the now somewhat broader-ecosystem qt4/
kde4. So getting buy-in for the quick deprecation of qt in favor of qt3
was much closer to simply getting by-in from the gentoo/kde folks (with a
large overlap between them and the gentoo/qt folks), as opposed to the
wider cooperation needed in the gtk case.

So to a large extent the fact that gtk means any gtk while the versioned
ones mean prefer that version, while there's ONLY the versioned qtX
flags, is an accident of history. And since then, the respective gtk/qt
policies have remained in place due to inertia -- yes there's an
inconsistency between them, but users of each quickly get comfortable
with it, and the cost-benefit ratio of trying to change either one now,
simply hasn't been considered worth it. Thus as new versions appear,
gtk3 and now qt5, they simply follow type.

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

Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.