[gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Stefan Schweizer
with kde4 approaching and the new Qt-4 being in the tree we suddenly see the
same problems that gtk had with the gtk2 flag again.
I am currently using the flags that way:
[ebuild R ] app-text/poppler-bindings-0.5.3 USE="cairo gtk qt qt4" 0 kB
so qt = qt3. Now that scheme will sure break when people start using the qt
useflag for applications that only use qt4. Now cardoe thinks a qt3 useflag
would make sense to disable qt3 support easily:
sys-apps/dbus-0.62 USE="X gtk mono python -qt3 qt4 -debug -doc" 0 kB
I do not think it there should be different useages of the qt, qt3 and qt4
useflag all over the tree, so there are a few options:
1) enable qt4 and qt3 by default when both are possible, and merge the qt4
and qt3 useflags currently in the tree into one qt useflag. What we lose
here is use.masking qt4, I think this will only be an option when qt4 is
marked for all architectures that qt3 is marked for.
2) use qt for qt3 only and a special qt4 for qt4. This is what I did
originally and it makes sense if done right. However when paackages with
qt4 start using the qt4 useflag you can no longer do USE="-qt" to disable
qt3 and the concept breaks.
3) split the qt flag into a qt3 and a qt4 flag. This allows users to
specifically pick qt3 or qt4 and the flag meanings are obvious - downsides
are it is a lot of work.
4) do nothing and happyly use the qt useflag for qt3 or qt4 as well as
sometimes a qt3 useflag or a qt4 useflag, just how the maintainer likes
it :) This is also not that bad since we do not need to set any rules here.
But it might be confusing and makes it impossible to disable all qt3 uses
or all qt4 uses
Currently we are at 4), should we change anything?
Regards,
Stefan
--
gento...@gentoo.org mailing list
Diego 'Flameeyes' Pettenò
> 3) split the qt flag into a qt3 and a qt4 flag. This allows users to
> specifically pick qt3 or qt4 and the flag meanings are obvious - downsides
> are it is a lot of work.
see for gtk too.
--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
Harald van Dijk
> On Tuesday 20 June 2006 18:40, Stefan Schweizer wrote:
> > 3) split the qt flag into a qt3 and a qt4 flag. This allows users to
> > specifically pick qt3 or qt4 and the flag meanings are obvious - downsides
> > are it is a lot of work.
> I would like migration to this idea, that would have been what I've liked to
> see for gtk too.
Same here, both for gtk and for qt. Also, with qt it's slightly worse
than with gtk: qt3 and qt4 are both huge, so if at all possible, I'd
like to not see a requirement to install both qt3 and qt4 just to get
poppler-bindings support for one (which would be required with a single
flag).
--
gento...@gentoo.org mailing list
Joshua Jackson
Hash: SHA1
Diego 'Flameeyes' Pettenň wrote:
> On Tuesday 20 June 2006 18:40, Stefan Schweizer wrote:
>> 3) split the qt flag into a qt3 and a qt4 flag. This allows users
>> to specifically pick qt3 or qt4 and the flag meanings are obvious
>> - downsides are it is a lot of work.
> I would like migration to this idea, that would have been what I've
> liked to see for gtk too.
>
Gtk did, do this. We had GTK and GTK2 once upon a time. We removed it
and basically said that its up to the maintainer to decide which gtk
version a application was going to use and the gtk use flag would be
used for that.
I don't want to go down the path again of having two nearly identical
flags for a different slotted version of a framework. I'd like to see
just qt with a maintainer deciding if its going to be qt3 or qt4.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEmCv9SENan+PfizARArgRAJ45Cyc52Cncg1BXU4/f7+whFZtDXwCcCZrN
iszdqTyb2263H8x7fFM6gxI=
=Iai+
-----END PGP SIGNATURE-----
--
gento...@gentoo.org mailing list
Diego 'Flameeyes' Pettenò
> I don't want to go down the path again of having two nearly identical
> flags for a different slotted version of a framework. I'd like to see
> just qt with a maintainer deciding if its going to be qt3 or qt4.
but deprecated right now. If you decide to use just one version of qt, it
would be qt3 for all, and a mess when KDE 4 will come out, we can't think of
NOT having time for the change from 3.x to 4.
Also, gtk and gtk2 flags did NOT work as I asked, gtk2 was to enable gtk2
version when both a 1.2 and 2 version was available, so for instance ethereal
+gtk -gtk2 built gtk 1.2, and -gtk +gtk2 built NOTHING. What I'm asking is
for qt3 enable the qt3 version, qt4 the qt4 version, qt3 and qt4 both if
possible (that is usually the case for stuff that has both version available,
as one does not obsolete the other right now).
Simon Stelling
same time (i.e. you have two interfaces, one against each, which is pretty
senseless), wouldn't something like
qt? ( || (=x11-libs/qt-3* =x11-libs/qt-4*))
be the best solution? It would allow the maintainer to set a reasonable default,
but in case the user only has the other version, it would take that one. If both
are installed, the one that the maintainer deemed the best is chosen.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Developer
--
gento...@gentoo.org mailing list
Steev Klimaszewski
What about something like dbus? Qt3 and Qt4 bindings, for apps that use
Qt3 and Qt4 (different applications using different versions of Qt) but
still using the dbus bindings...
--
gento...@gentoo.org mailing list
Diego 'Flameeyes' Pettenò
> I don't know all the details, but assuming no app supports qt3 and qt4 at
> the same time (i.e. you have two interfaces, one against each, which is
> pretty senseless), wouldn't something like
Would you accept being able to build only either python or perl bindings for a
package, depending on what the maintainer thought it was the best for you?
Marius Mauch
"Diego 'Flameeyes' Pettenò" <flam...@gentoo.org> wrote:
> On Tuesday 20 June 2006 19:10, Joshua Jackson wrote:
> > I don't want to go down the path again of having two nearly
> > identical flags for a different slotted version of a framework. I'd
> > like to see just qt with a maintainer deciding if its going to be
> > qt3 or qt4.
> Unfeasible. GTK 1.2 was deprecated when the two flags were merged,
> Qt3 is all but deprecated right now. If you decide to use just one
> version of qt, it would be qt3 for all, and a mess when KDE 4 will
> come out, we can't think of NOT having time for the change from 3.x
> to 4.
>
> Also, gtk and gtk2 flags did NOT work as I asked, gtk2 was to enable
> gtk2 version when both a 1.2 and 2 version was available, so for
> instance ethereal +gtk -gtk2 built gtk 1.2, and -gtk +gtk2 built
> NOTHING. What I'm asking is for qt3 enable the qt3 version, qt4 the
> qt4 version, qt3 and qt4 both if possible (that is usually the case
> for stuff that has both version available, as one does not obsolete
> the other right now).
I don't mind the qt3/qt4 flags for packages that support both, but could
we also have a qt flag that selects the "preferred" version (or for
packages that only support one)? Many people simply don't care about the
version but also don't need support for both in every package, also
that makes transition easier IMHO.
Though that creates a problem when both the unversioned and one of the
versioned flags are used, not sure how to deal with that.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
Caleb Tennis
My proposal:
I would personally like to stay with just the "qt" use flag. The use flag
will be for support of whichever version of Qt is supported (v3 or v4) for
the particular emerge.
In the cases where more than one version is supported, it should be for
Qt4 only. The Qt3 version should be a separate emerge. For example, in
the case of the poppler bindings, there should be a poppler-bindings-qt3
package.
It's not pretty, but I think it's the best tradeoff we have.
Caleb
--
gento...@gentoo.org mailing list
Steve Dibb
> I don't mind the qt3/qt4 flags for packages that support both, but could
> we also have a qt flag that selects the "preferred" version (or for
> packages that only support one)? Many people simply don't care about the
> version but also don't need support for both in every package, also
> that makes transition easier IMHO.
> Though that creates a problem when both the unversioned and one of the
> versioned flags are used, not sure how to deal with that.
>
ignore me -- I'm new here. :)
What about having a variable in make.conf, something like
USE_QT_VERSIONS, where you could put the preferred Qt versions that
you'd like support built for?
So, for example, if I wanted Qt3 and Qt4 support, I'd put
USE_QT_VERSIONS="3 4" in make.conf. If I wanted one and not the other,
just put in "3" or "4" instead.
That way, you could still keep just one "qt" USE flag.
Steve
--
gento...@gentoo.org mailing list
Marius Mauch
Steve Dibb <bea...@gentoo.org> wrote:
> Marius Mauch wrote:
> > I don't mind the qt3/qt4 flags for packages that support both, but
> > could we also have a qt flag that selects the "preferred" version
> > (or for packages that only support one)? Many people simply don't
> > care about the version but also don't need support for both in
> > every package, also that makes transition easier IMHO.
> > Though that creates a problem when both the unversioned and one of
> > the versioned flags are used, not sure how to deal with that.
> >
> That gives me an idea, and if this has been suggested before, just
> ignore me -- I'm new here. :)
>
> What about having a variable in make.conf, something like
> USE_QT_VERSIONS, where you could put the preferred Qt versions that
> you'd like support built for?
That would require quite a bit of effort for a single special case,
depending how exactly you want to implement it it's likely gonna screw
up with the cache as well, so not really an option.
Donnie Berkholz
My counterproposal:
The newest version of any package should always have the unversioned
flag. Versioned flags should be for a conscious choice to use a less
current package.
I disagree with separate packages, if it's possible to build both at
once. That's the point of USE flags.
Thanks,
Donnie
Caleb Tennis
> once. That's the point of USE flags.
I'd say that's fine in the general case, but with a slotted package it's
going to be extremely messy.
I think we're in agreement that "qt" should represent the most recent
version supported by the particular package.
If people want to create local use flags for the older qt3 version, I
suppose that's ok, but I think you're going to start running into using a
lot of "build_with_use" statements to see if that version was built or
not. It seems cleaner from the ebuild perspective just to be able to put
in a dep on a package name rather than a pseudo-hack in order to support
multiple interfaces via a single ebuild.
Henrik Brix Andersen
> I would personally like to stay with just the "qt" use flag. The use flag
> will be for support of whichever version of Qt is supported (v3 or v4) for
> the particular emerge.
I would like a single 'qt' USE flag as well. If a package supports
multiple versions of Qt, it can easily be tested which one is
available at build time, see for instance
net-wireless/wpa_supplicant-0.5.3.
> In the cases where more than one version is supported, it should be for
> Qt4 only. The Qt3 version should be a separate emerge. For example, in
> the case of the poppler bindings, there should be a poppler-bindings-qt3
> package.
How about using my idea from above (if USE=qt, then check which
version(s) of Qt is available and compile in support for those)?
Regards,
Brix
--
Henrik Brix Andersen <br...@gentoo.org>
Gentoo Metadistribution | Mobile computing herd
Donnie Berkholz
> On Tue, Jun 20, 2006 at 03:11:38PM -0400, Caleb Tennis wrote:
>> I would personally like to stay with just the "qt" use flag. The use flag
>> will be for support of whichever version of Qt is supported (v3 or v4) for
>> the particular emerge.
>
> I would like a single 'qt' USE flag as well. If a package supports
> multiple versions of Qt, it can easily be tested which one is
> available at build time, see for instance
> net-wireless/wpa_supplicant-0.5.3.
>
>> In the cases where more than one version is supported, it should be for
>> Qt4 only. The Qt3 version should be a separate emerge. For example, in
>> the case of the poppler bindings, there should be a poppler-bindings-qt3
>> package.
>
> How about using my idea from above (if USE=qt, then check which
> version(s) of Qt is available and compile in support for those)?
That makes for highly irreproduceable builds and particularly screws
with building packages on one machine and expecting them to work on
another. Same as autodetecting in configure scripts, except worse
because now we're doing it too.
Thanks,
Donnie
Kevin F. Quinn
+lots
Ebuilds should not use the build system to make choices about the
target, such choices should be USE based as far as possible. The build
system should only be considered when ensuring sufficient support is
available to perform the build.
Always consider what happens if you build a binpkg (emerge -B) then try
to install that binpkg on another machine (emerge -K).
In this particular case, I think separate qt3 and qt4 use flags are
sensible and clear. If both are specified, the package should build
both UIs; if only one can be built the ebuild should reject the USE flag
combinations it can't support.
Problems with having 'qt' to mean latest and 'qt3' as specifically
version 3 include:
1) Target package depends on build system (assuming 'qt' is interpreted
as 'qt3' if only that is installed, rather than pulling in qt4 if not
already present).
2) What 'qt' means changes as new releases are made - if/when qt5
becomes available, it means introducing a qt4 use flag and back-fitting
to existing ebuilds that used 'qt' but don't build against qt5.
--
Kevin F. Quinn
Donnie Berkholz
> Problems with having 'qt' to mean latest and 'qt3' as specifically
> version 3 include:
>
> 1) Target package depends on build system (assuming 'qt' is interpreted
> as 'qt3' if only that is installed, rather than pulling in qt4 if not
> already present).
What? There will still be versioned dependencies in the ebuilds.
> 2) What 'qt' means changes as new releases are made - if/when qt5
> becomes available, it means introducing a qt4 use flag and back-fitting
> to existing ebuilds that used 'qt' but don't build against qt5.
This is mostly untrue. The 'qt' flag means "build against the latest
available qt that _this package supports_, not an absolute "build
against qt5." Yes, you will need to introduce a qt4 flag as upstreams
port packages to qt5, if they choose to also retain a qt4 frontend.
Thanks,
Donnie
Mike Owen
> Hi,
>
> with kde4 approaching and the new Qt-4 being in the tree we suddenly see the
> same problems that gtk had with the gtk2 flag again.
>
From this user's perspective, simple is better. qt3 and qt4 as use
flags are completely and utterly obvious as to what they mean, and
there is no confusion about them. Adding a plain qt flag in there
brings back the gtk/gtk2 mess that we've presumably been trying to
avoid in the future.
Mike
--
gento...@gentoo.org mailing list
Donnie Berkholz
> From this user's perspective, simple is better. qt3 and qt4 as use
> flags are completely and utterly obvious as to what they mean, and
> there is no confusion about them. Adding a plain qt flag in there
> brings back the gtk/gtk2 mess that we've presumably been trying to
> avoid in the future.
That depends on how it's done. If it's done in a simple and obvious way
(USE=qt means use the best available qt, USE=qt# for other weird stuff
that most people don't care about and so can ignore), it shouldn't be
that bad.
Thanks,
Donnie
Diego 'Flameeyes' Pettenò
> Yes, you will need to introduce a qt4 flag as upstreams
> port packages to qt5, if they choose to also retain a qt4 frontend.
gtk regards only the graphic library, qt is a library of utility functions
too. Qt can be considered like gtk+glib, and that make things more complex.
As I said, I'd rather see two flags, qt3 and qt4, to identify the two
versions. A simpler alternative would be qt (defaults to 3) and qt4, but
that's going to be confused on the long run to something similar to gtk.
Donnie Berkholz
> On Wednesday 21 June 2006 00:52, Donnie Berkholz wrote:
>> Yes, you will need to introduce a qt4 flag as upstreams
>> port packages to qt5, if they choose to also retain a qt4 frontend.
> You're trying to compare gtk to qt directly. They are not the same.
> gtk regards only the graphic library, qt is a library of utility functions
> too. Qt can be considered like gtk+glib, and that make things more complex.
How does that matter in this context?
> As I said, I'd rather see two flags, qt3 and qt4, to identify the two
> versions. A simpler alternative would be qt (defaults to 3) and qt4, but
> that's going to be confused on the long run to something similar to gtk.
I disagree with this and agree with Caleb's earlier suggestion.
Presumably he has some clue what he's talking about when it comes to qt.
Thanks,
Donnie
Diego 'Flameeyes' Pettenò
> I disagree with this and agree with Caleb's earlier suggestion.
> Presumably he has some clue what he's talking about when it comes to qt.
if you want to put it this way, I have more clues than you when it comes to
interfacing with users.
But _that_ is what you asked me to say.
Donnie Berkholz
> On Wednesday 21 June 2006 02:12, Donnie Berkholz wrote:
>> I disagree with this and agree with Caleb's earlier suggestion.
>> Presumably he has some clue what he's talking about when it comes to qt.
> I suppose he has, that does not mean that I don't have any at all. Probably,
> if you want to put it this way, I have more clues than you when it comes to
> interfacing with users.
I never said you didn't. And there's no need to bring in completely
offtopic points here, we're trying to have a discussion about qt.
> But _that_ is what you asked me to say.
Not really, I want you to say something about qt.
Thanks,
Donnie
Diego 'Flameeyes' Pettenò
> I never said you didn't. And there's no need to bring in completely
> offtopic points here, we're trying to have a discussion about qt.
users, that are, casually, the main users of Qt-related stuff.
In this particular issue, KDE (3) users are the main part, they need poppler
and other stuff built for Qt 3. There are still just a few packages that
relies on Qt 4 right now.
Still, I'm not for the idea of just putting qt to mean Qt 3 and discard Qt 4
until it's "the chosen one", not only for a compatibility reason with
migration from older version, but also because we do have people using gentoo
for KDE 4 development (I happen to know a few of them), and they need Qt 4
support.
I want to save both of them, asking a little bit more work for the developers,
as they usually know what to do, rather than for users, which might as well
be half clueless.
Did I explain this long enough, or should I demonstrate again that I don't say
stuff just because I have a mail client and a GPG signature?
Donnie Berkholz
> I am talking about qt. Maybe I wasn't clear enough, I was thinking of KDE
> users, that are, casually, the main users of Qt-related stuff.
>
> In this particular issue, KDE (3) users are the main part, they need poppler
> and other stuff built for Qt 3. There are still just a few packages that
> relies on Qt 4 right now.
OK, so we can add qt3 to make.defaults.
> Still, I'm not for the idea of just putting qt to mean Qt 3 and discard Qt 4
> until it's "the chosen one", not only for a compatibility reason with
> migration from older version, but also because we do have people using gentoo
> for KDE 4 development (I happen to know a few of them), and they need Qt 4
> support.
>
> I want to save both of them, asking a little bit more work for the developers,
> as they usually know what to do, rather than for users, which might as well
> be half clueless.
I don't see how any other suggestion is simpler than mine for developers
or users. Maybe I missed something in skimming the discussion.
To summarize:
- USE=qt enables support for the most current qt.
- USE=qt3 enables qt3 if there is also qt4 interface. This will be an
easy switch now, because very few packages have a qt4 flag, and it will
get progressively harder.
- Add qt3 to make.defaults to avoid breaking things like KDE.
I suppose it will also need some clause for the mutually exclusive cases:
USE="qt -qt3" enables most recent
any USE combination containing qt3 forces back to qt3
Thanks,
Donnie
Diego 'Flameeyes' Pettenò
> OK, so we can add qt3 to make.defaults.
-* says nothing to you? :)
I was looking at the less work possible for both users and bug wranglers.
Still, I think you took too personally the fact that I cleared up the gtk+glib
vs qt stuff; maybe that's my fault, I want to clear that up so that people
not used to know how qt works can know the situation, as the idea of dropping
one of the two support stated in other mails of this thread and on IRC is
something really unfeasible.
Dan Meltzer
> Diego 'Flameeyes' Pettenò wrote:
[snip]
> I don't see how any other suggestion is simpler than mine for developers
> or users. Maybe I missed something in skimming the discussion.
>
> To summarize:
>
> - USE=qt enables support for the most current qt.
>
> - USE=qt3 enables qt3 if there is also qt4 interface. This will be an
> easy switch now, because very few packages have a qt4 flag, and it will
> get progressively harder.
>
> - Add qt3 to make.defaults to avoid breaking things like KDE.
>
> I suppose it will also need some clause for the mutually exclusive cases:
> USE="qt -qt3" enables most recent
> any USE combination containing qt3 forces back to qt3
>
One problem I see with this is users that currently have -qt are going
to be confused when it no longer does what they expect
> Thanks,
> Donnie
>
>
>
>
--
gento...@gentoo.org mailing list
Donnie Berkholz
> On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote:
>> OK, so we can add qt3 to make.defaults.
> Firulì Firulà (sounds of whistling in Italy at least)
>
> -* says nothing to you? :)
Sure it does, but -* has always been unsupported and users are on their
own to watch USE flag changes when using it.
> I was looking at the less work possible for both users and bug wranglers.
> Still, I think you took too personally the fact that I cleared up the gtk+glib
> vs qt stuff; maybe that's my fault, I want to clear that up so that people
> not used to know how qt works can know the situation, as the idea of dropping
> one of the two support stated in other mails of this thread and on IRC is
> something really unfeasible.
I'm trying to find the easiest answer too, we're on the same side here. =)
Thanks,
Donnie
Kevin F. Quinn
Donnie Berkholz <spyd...@gentoo.org> wrote:
> Mike Owen wrote:
> > From this user's perspective, simple is better. qt3 and qt4 as use
> > flags are completely and utterly obvious as to what they mean, and
> > there is no confusion about them. Adding a plain qt flag in there
> > brings back the gtk/gtk2 mess that we've presumably been trying to
> > avoid in the future.
>
> That depends on how it's done. If it's done in a simple and obvious
> way (USE=qt means use the best available qt, USE=qt# for other weird
where "available" means "available in the tree for arch", not
"already installed on build system" (just to be clear - correct me if
I'm wrong)
> stuff that most people don't care about and so can ignore), it
> shouldn't be that bad.
So are you suggesting something like:
qt - Add support for QT/include QT GUI
qt3 - build for version 3 of QT
where dependencies might be something like:
qt? ( qt3? ( >=dev-libs/qt-3.3.6
<dev-libs/qt-4 )
!qt3? ( >= dev-libs/qt-4.1 ) )
for a package that can build against either qt3 (3.3.6 or higher) or
qt4 (4.1 or higher) but not both simultaneously, and perhaps:
qt? ( >= dev-libs/qt-4.1
qt3? ( >=dev-libs/qt-3.3.6
<dev-libs/qt-4 ) )
for packages that can build simultaneously for both (is this situation
realistic?). We'd need a qt4 to get just the qt3 package in that case:
qt? ( qt4? ( >= dev-libs/qt-4.1 )
qt3? ( >=dev-libs/qt-3.3.6
<dev-libs/qt-4 ) )
Am I making sense? This looks a lot like the gtk/gtk2 flags, but
inverted; according to use.desc, gtk builds gtk+-1 unless gtk2 is set,
whereas the above builds highest version compatible with the
package unless a lower version is specifically requested through USE.
Ideally we should be consistent in handling this issue (which
presumably isn't limited to just gtk and qt), although it may not be
worth the disruption to rework gtk/gtk2 into gtk/gtk1.
--
Kevin F. Quinn
Donnie Berkholz
> On Tue, 20 Jun 2006 16:14:08 -0700
> Donnie Berkholz <spyd...@gentoo.org> wrote:
>
>> Mike Owen wrote:
>>> From this user's perspective, simple is better. qt3 and qt4 as use
>>> flags are completely and utterly obvious as to what they mean, and
>>> there is no confusion about them. Adding a plain qt flag in there
>>> brings back the gtk/gtk2 mess that we've presumably been trying to
>>> avoid in the future.
>> That depends on how it's done. If it's done in a simple and obvious
>> way (USE=qt means use the best available qt, USE=qt# for other weird
>
> where "available" means "available in the tree for arch", not
> "already installed on build system" (just to be clear - correct me if
> I'm wrong)
Yes, but it's more than that.
Available will vary on a package-by-package basis. Package "A" may have
qt4 and qt3 available, package "B" only qt4, package "C" only qt3.
USE=qt would use qt4 on A, qt4 on B, qt3 on C.
USE=qt3 would only affect A.
>> stuff that most people don't care about and so can ignore), it
>> shouldn't be that bad.
>
> So are you suggesting something like:
>
> qt - Add support for QT/include QT GUI
> qt3 - build for version 3 of QT
>
> where dependencies might be something like:
>
> qt? ( qt3? ( >=dev-libs/qt-3.3.6
> <dev-libs/qt-4 )
> !qt3? ( >= dev-libs/qt-4.1 ) )
Well, I'm not sure of the best behavior. If they have USE="qt qt3",
they're saying they want both the best available qt and qt3. I'd suggest
the natural preference would be best available _over_ qt3, in cases
where both are available and mutually exclusive.
So more like:
qt? ( =qt-4* )
!qt? ( qt3? ( =qt-3* ) )
Your inital dep string may not do what you intend, though. Something
more like
=qt-3*
=qt-4* for the two sections
> for a package that can build against either qt3 (3.3.6 or higher) or
> qt4 (4.1 or higher) but not both simultaneously, and perhaps:
>
> qt? ( >= dev-libs/qt-4.1
> qt3? ( >=dev-libs/qt-3.3.6
> <dev-libs/qt-4 ) )
>
> for packages that can build simultaneously for both (is this situation
> realistic?).
Yes, e.g. poppler-bindings
> We'd need a qt4 to get just the qt3 package in that case:
>
> qt? ( qt4? ( >= dev-libs/qt-4.1 )
> qt3? ( >=dev-libs/qt-3.3.6
> <dev-libs/qt-4 ) )
No, this isn't right. The qt flag is only controlling whether the "best"
interface is built, has nothing to do with older interfaces.
qt? ( =qt-4* )
qt3? ( =qt-3* )
The goal is to avoid a double-flag combo to do a single thing. "qt"
always and only affects the _best_ available qt interface for that
package. "qt#" affects only _older_ available qt interfaces for that
package.
> Am I making sense? This looks a lot like the gtk/gtk2 flags, but
> inverted; according to use.desc, gtk builds gtk+-1 unless gtk2 is set,
> whereas the above builds highest version compatible with the
> package unless a lower version is specifically requested through USE.
>
> Ideally we should be consistent in handling this issue (which
> presumably isn't limited to just gtk and qt), although it may not be
> worth the disruption to rework gtk/gtk2 into gtk/gtk1.
Thanks,
Donnie
Michael Sterrett -Mr. Bones.-
> Am I making sense? This looks a lot like the gtk/gtk2 flags, but
> inverted; according to use.desc, gtk builds gtk+-1 unless gtk2 is set,
> whereas the above builds highest version compatible with the
> package unless a lower version is specifically requested through USE.
That's not what use.desc says gtk does. You just illustrated how confusing
the gtk/gtk2 use flag situation has been.
The gtk use flag doesn't specify a version. It just says that the package
should build against *a* version of gtk+. The gtk2 flag was a way to
prefer the gtk2 interface over the gtk1 interface if a package supported
both.
Thankfully, we've mostly moved past the gtk/gtk2 use flag mess now.
Let's try not to make it quite so hard for people with the qt toolkit.
Michael Sterrett
-Mr. Bones.-
mr_b...@gentoo.org
--
gento...@gentoo.org mailing list
Stefan Schweizer
> I would personally like to stay with just the "qt" use flag. The use flag
> will be for support of whichever version of Qt is supported (v3 or v4) for
> the particular emerge.
>
> In the cases where more than one version is supported, it should be for
> Qt4 only. The Qt3 version should be a separate emerge. For example, in
> the case of the poppler bindings, there should be a poppler-bindings-qt3
> package.
The problem here is that a user cannot just say at one point "I do not want
any more qt3 packages on my system". He will need a
big /etc/portage/package.use list to do it. That is the same problem I
currently have with gtk1 - I would like to avoid it for qt.
Considering we only have 36 packages [1] with a qt useflag it will be fairly
easy to convert them to a qt3/qt4 version system that makes sense to
everyone and allows easy enabling/disabling of only qt3 or qt4.
[1] http://gentoo-portage.com/Search?search=&use=qt
this scheme also allows some people to disable qt4 just with USE="-qt4" and
mask it. Any optional qt4 interfaces wont be built then. With only a qt
useflag this would require a package.use list again.
Can we think about it again? 36 packages is less than half what currently
still uses gtk1 in the tree. Doing it right for the users is better than
doing it easy for the package maintainers.
Thanks,
Stefan
--
gento...@gentoo.org mailing list
George Shapovalov
> On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote:
> > OK, so we can add qt3 to make.defaults.
My understanding of that proposal was that qt3 is meant to mean "prefer qt3
over qt4", rather than "enable qt3 unconditionally and see what can be done
about qt4". So which one is that?
If it is former (preference flag) I do not see aproblem there:
-qt +qt3 = -qt in such reading.
So, basically the question is about interpretation of -qt +qt3 construct..
George
--
gento...@gentoo.org mailing list
Jakub Moc
> ??????, 21. ??????? 2006 03:46, Diego 'Flameeyes' Petteno` ?? ????????:
>> On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote:
>>> OK, so we can add qt3 to make.defaults.
>> -* says nothing to you? :)
> Now I am confused:
> My understanding of that proposal was that qt3 is meant to mean "prefer qt3
> over qt4", rather than "enable qt3 unconditionally and see what can be done
> about qt4". So which one is that?
> If it is former (preference flag) I do not see aproblem there:
> -qt +qt3 = -qt in such reading.
> So, basically the question is about interpretation of -qt +qt3 construct..
>
> George
And, USE='qt -qt3 -qt4' means? See, this gets very tricky and makes for
butt-ugly dependency and other constructs in ebuilds once more than two
flags get involved, as the various combos start be nonsensical. Also,
users generally "rock" in inventing sucky use flag combos and
interpreting them in most whacky ways. Turns bugs into discussions about
what a particular use flag (or combo of flags) should mean. It's very
hard to ensure consistent use in all ebuilds. Will just do more harm
than good. I've seen a major decline of this type of bugs since the
gtk/gtk2 mess got more or less sorted out, we shouldn't repeat past
mistakes.
--
Best regards,
Jakub Moc
mailto:ja...@gentoo.org
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E
... still no signature ;)
Kevin F. Quinn
"Michael Sterrett -Mr. Bones.-" <mste...@coat.com> wrote:
> On Wed, 21 Jun 2006, Kevin F. Quinn wrote:
>
> > Am I making sense? This looks a lot like the gtk/gtk2 flags, but
> > inverted; according to use.desc, gtk builds gtk+-1 unless gtk2 is
> > set, whereas the above builds highest version compatible with the
> > package unless a lower version is specifically requested through
> > USE.
>
> That's not what use.desc says gtk does. You just illustrated how
> confusing the gtk/gtk2 use flag situation has been.
>
> The gtk use flag doesn't specify a version. It just says that the
> package should build against *a* version of gtk+. The gtk2 flag was
> a way to prefer the gtk2 interface over the gtk1 interface if a
> package supported both.
ok; so in gtk-land we have gtk2 to prefer the newer interface whereas
the proposal for qt/qt3 is to have a specific flag for the older
interface. I do prefer the qt/qt3 approach, even though it's
inconsistent with what happens on gtk. I don't suppose changing
gtk/gtk2 to gtk/gtk1 would be popular...
> Thankfully, we've mostly moved past the gtk/gtk2 use flag mess now.
> Let's try not to make it quite so hard for people with the qt toolkit.
I think we're all agreed there :) So it's worth thrashing out properly.
--
Kevin F. Quinn
Kevin F. Quinn
Donnie Berkholz <spyd...@gentoo.org> wrote:
> Kevin F. Quinn wrote:
> > On Tue, 20 Jun 2006 16:14:08 -0700
> > Donnie Berkholz <spyd...@gentoo.org> wrote:
> >
> > [...]
Thanks for the clarification
> The goal is to avoid a double-flag combo to do a single thing. "qt"
> always and only affects the _best_ available qt interface for that
> package. "qt#" affects only _older_ available qt interfaces for that
> package.
OK; so with this we're not providing a way to get an "only qt3" system
or "only qt4" via USE flags. Perhaps users can do that with local
masking, provided ebuilds that can build against both depend on all the
relevant versions:
qt? || ( =dev-libs/qt-3.3* =dev-libs/qt-4.1* )
--
Kevin F. Quinn
Diego 'Flameeyes' Pettenò
> ok; so in gtk-land we have gtk2 to prefer the newer interface whereas
> the proposal for qt/qt3 is to have a specific flag for the older
> interface. I do prefer the qt/qt3 approach, even though it's
> inconsistent with what happens on gtk. I don't suppose changing
> gtk/gtk2 to gtk/gtk1 would be popular...
so talking about frontends and interface is misleading. If it was just
interface, of course it would be possible to choose the best between Qt4 and
Qt3, but this is not an interface problem, it's a bindings problem.
As I said, enabling just one between qt3 and qt4 in bindings would be like
just having one of "pbindings" useflag, and every ebuild decides if it will
provide python or perl bindings, just because they happen to start with 'P'.
Qt3 and Qt4 are different enough to be considered different languages from
some POVs, it does not make sense to treat Qt the exact same way of GTK,
because it's not only a GUI thing.
Caleb Tennis
> Hi,
>
> with kde4 approaching and the new Qt-4 being in the tree we suddenly see
> the same problems that gtk had with the gtk2 flag again.
I think there's a lot of good thoughts surrounding how to handle this. There
are 2 categories of packages we need to concern ourselves with:
1) A package can optionally add support for Qt3 or Qt4 (such as dbus).
Solution: The qt flag represents the latest qt major version for the package.
The maintainer can either put in another flag for the older version (qt3?) or
provide a separate package (e.g. dbus-qt3 ).
2) A package requires either Qt3 or Qt4 (both not both?...such as
x11-libs/qwt-5).
Solution: Build against qt4. If you want to provide the same package for the
qt3 version, add a new package to portage I suppose.
--------
In the end, this is just merely suggestion. I think each maintainer should
come up with the best way to handle the situation unless someone is going to
GLEP this.
I think we should, however, do our best to avoid a situation where we have
some ugly combination of USE="qt -qt3" or USE="qt4 -qt qt3"...
--
gento...@gentoo.org mailing list
Stefan Schweizer
> On Tuesday 20 June 2006 12:40, Stefan Schweizer wrote:
>> Hi,
>>
>> with kde4 approaching and the new Qt-4 being in the tree we suddenly see
>> the same problems that gtk had with the gtk2 flag again.
>
> I think there's a lot of good thoughts surrounding how to handle this.
> There are 2 categories of packages we need to concern ourselves with:
>
> 1) A package can optionally add support for Qt3 or Qt4 (such as dbus).
>
qt3 and qt4 is being used there already and it is obvious
> 2) A package requires either Qt3 or Qt4 (both not both?...such as
> x11-libs/qwt-5).
qt3 - enable optional qt3 support
qt4 - enable optional qt4 support
when both are possible its the maintainers decision, would look something
like this:
qt4? ( =x11-libs/qt-4* )
!qt4? ( qt3? ( =x11-libs/qt-3* )
Why you ask? Because a user does not care if packageX uses qt3 or qt4, he
just wants to use it.
But why do we have two useflags then?
Because the user should be able to disable optional support for either qt3
or qt4 or both for every package.
Disabling all optional qt4 support is only conveniently possible with a qt4
flag. Same for qt3.
We need separate flags here, otherwise you can just use one flag for
everything, it does not make sense to have two flags when one cannot be
used because the other is ambiguous.
> Solution: Build against qt4. If you want to provide the same package for
> the qt3 version, add a new package to portage I suppose.
This "add a new package to portage" is not really the gentoo spirit of
following upstream tarballing, in my opinion.
> In the end, this is just merely suggestion. I think each maintainer
> should come up with the best way to handle the situation unless someone is
> going to GLEP this.
We have 36 qt-use-packages, so we could have 36 different flags in the
end ;)
Trying to reach a consensus on the mailing list is a better idea imo.
> I think we should, however, do our best to avoid a situation where we have
> some ugly combination of USE="qt -qt3" or USE="qt4 -qt qt3"...
right you are. And since we already have a qt3 and a qt4 useflag in the tree
it is a good move to do this right.
--
gento...@gentoo.org mailing list
Donnie Berkholz
-qt +qt3:
This would only be available in 2 cases:
- Package supports both qt4 and qt3, and they're mutually exclusive
- Package supports both qt4 and qt3, and they can both be enabled at once
In case 1, "-qt +qt3" would enable qt3. In case 2, "-qt +qt3" would
enable qt3.
In other words, as I've been trying to say all along, there is no such
thing as a preference flag here. That creates a 2-flag combination to
get a single feature, which is _not_ what we want. There is a "qt" flag
to indicate enabling the best available qt for that package, and there
are "qt#" flags to indicate enabling older qt for that package.
The downside to this setup is that it's difficult to avoid installing
certain qt versions when it's unknown which version USE=qt will pull in
for any given package. This favors an entirely versioned setup instead,
and we should get rid of USE=qt altogether in favor of only USE=qt#.
Thanks,
Donnie
Diego 'Flameeyes' Pettenò
> Solution: The qt flag represents the latest qt major version for the
> package. The maintainer can either put in another flag for the older
> version (qt3?) or provide a separate package (e.g. dbus-qt3 ).
asap), right now I think it's going to be a bit of a mess for KDE users,
Remember we don't have use-deps and that splitting packages is something
that, if done without upstream support, can give very bad headaches (we both
know how KDE split is right now).
Also, this puts us back again in gtk's system, with different meaning for the
same flag (qt can then either be for Qt3 or Qt4, no clear distinction), that
might even change on maintainer's decision, becoming a mess to handle in
dependent packages.
Why you think it's better this way rather than having one meaning every
useflag?
Another thing that this setup is going to make incredibly difficult to manage
is use.mask masking on profiles. If for some reasons Qt3 or Qt4 needs to be
masked on a profile, even temporarily, by having qt mean one or the other
depending on the package is going to be a mess as we don't have per-package
use.mask (and we won't have till portage 2.2 gets the main scene). This is
another of the main reasons I don't think it's a good idea to overload
useflags with different (albeit slightly) meanings.
I agree on the other part tho, pushing Qt4 is indeed a good idea, although it
might mess up the look&feel of a desktop, but that is marginally important.
Donnie Berkholz
>> The goal is to avoid a double-flag combo to do a single thing. "qt"
>> always and only affects the _best_ available qt interface for that
>> package. "qt#" affects only _older_ available qt interfaces for that
>> package.
>
> OK; so with this we're not providing a way to get an "only qt3" system
> or "only qt4" via USE flags. Perhaps users can do that with local
> masking, provided ebuilds that can build against both depend on all the
> relevant versions:
>
> qt? || ( =dev-libs/qt-3.3* =dev-libs/qt-4.1* )
Yes, I just mentioned elsewhere in the thread that this is a downside of
this design. Another possibility is getting rid of USE=qt and having
only USE=qt#.
Thanks,
Donnie
Caleb Tennis
> qt3 - enable optional qt3 support
> qt4 - enable optional qt4 support
Maybe I just need a little time to warm up to this. :)
Caleb
--
gento...@gentoo.org mailing list
Donnie Berkholz
> Why you ask? Because a user does not care if packageX uses qt3 or qt4, he
> just wants to use it.
>
> But why do we have two useflags then?
> Because the user should be able to disable optional support for either qt3
> or qt4 or both for every package.
There's a significant enough use case for wanting only qt3 or only qt4
on your system that it might be worth considering it.
>> I think we should, however, do our best to avoid a situation where we have
>> some ugly combination of USE="qt -qt3" or USE="qt4 -qt qt3"...
>
> right you are. And since we already have a qt3 and a qt4 useflag in the tree
> it is a good move to do this right.
Agreed on this. So right now, we've got a couple of options.
- Use case is user wants program with its best qt. USE=qt is an easy
option. The other option is USE="qt3 qt4", and apps should always pick
the best of the enabled qt versions if they are mutually exclusive.
- Use case is avoiding installing either qt3 or qt4. Impossible with
USE=qt, possible with USE="qt3/qt4".
Thanks,
Donnie
Carsten Lohrke
> qt3 and qt4 is being used there already and it is obvious
It's "nice" to invent new use flags affecting Qt stuff without contacting
those who care for Qt.
>
> > 2) A package requires either Qt3 or Qt4 (both not both?...such as
> > x11-libs/qwt-5).
>
> qt3 - enable optional qt3 support
> qt4 - enable optional qt4 support
That will be a mess to support in the long run. Let's go with that what works
better, prefer the latest version and be fine with it. I do agree with Caleb
to use the qt use flag for the latest supported version and in cases it is
really necessary to have an additional qt3 use flag.
Carsten
Harald van Dijk
> On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote:
> > qt3 - enable optional qt3 support
> > qt4 - enable optional qt4 support
>
> That will be a mess to support in the long run.
Why?
--
gento...@gentoo.org mailing list
Michael Sterrett -Mr. Bones.-
Sounds like:
qt - GLOBAL use flag that causes the package to build against the good version
for that package.
qt3, qt4... - LOCAL use flags to build against specific versions of
qt when it makes sense on a per-package basis and when it's deemed to
be reasonable by the package maintainer. Easy to keep track of because
they'd all be in use.local.desc.
Caleb Tennis
> version
> for that package.
>
> qt3, qt4... - LOCAL use flags to build against specific versions of
> qt when it makes sense on a per-package basis and when it's deemed to
> be reasonable by the package maintainer. Easy to keep track of because
> they'd all be in use.local.desc.
This is exactly what I recommend. It requires no end user changes to make
it work.
The only downside to this is that using "qt" isn't explicit in which
version it pulls in. To that, I say: who cares? That only seemingly
becomes valid when someone wants to "rid their system of a specific
version of Qt", which if they're advanced enough to think they need to do
that they can probably hack around enough to figure out that packages
depend on the version of Qt they want to nuke.
I seriously doubt there will ever be many packages that support both at
the same time. For those, we'll handle them in the best way we can at the
time, be it a qt3 flag, a separate package instance, or other.
Moreso, people will release new packages of existing products that use Qt4
instead of Qt3. This is where it gets interesting: if somelibrary-3.0
depends on Qt3 and somelibrary-4.0 depends on Qt4, do we slot them so they
can both be installed at the same time? Seems reasonable to do so, but
you run into the issue of how to handle version dependencies across slots
of the same package...something portage doesn't do very gracefully at the
moment.
Oh, the joys. :)
--
gento...@gentoo.org mailing list
Henrik Brix Andersen
> That makes for highly irreproduceable builds and particularly screws
> with building packages on one machine and expecting them to work on
> another. Same as autodetecting in configure scripts, except worse
> because now we're doing it too.
Oops, didn't think of that. I've fixed this in the newly added
net-wireless/wpa_supplicant-0.5.4 ebuild, thanks.
Regards,
Brix
--
Henrik Brix Andersen <br...@gentoo.org>
Gentoo Metadistribution | Mobile computing herd
Duncan
34384.192.168.2.159...@www.aei-tech.com, excerpted below,
on Wed, 21 Jun 2006 10:03:21 -0400:
> [Stefan Schweizer wrote...]
>> qt3 - enable optional qt3 support
>> qt4 - enable optional qt4 support
>
> Maybe I just need a little time to warm up to this. :)
This seems simplest here, too.
Deprecate USE=qt. With only 36 packages
in the tree using it, it shouldn't be difficult.
qt3 for qt3
qt4 for qt4
Thus, if either one is possible, no problem. If both are possible without
conflict, no problem.
The problems then come if one is required and USE=-qt3 -qt4, or in the
exclusive-or situation of USE=qt3 qt4 or USE=-qt3 -qt4, but only one can be
supported at once.
In both cases, defaulting to the later one (4 at this point) will be the
most future proof. make.defaults could include qt3 ATM, which would
solve the current KDE support problem for many. There may be a few cases
where defaulting to the later one in exclusive support situations may be
problematic, and those should be resolved by the package maintainer as
they would be on an individual case by case basis just as they would be
for any other USE flag conflicts. In some rare cases, a die with a message
directing the user to resolve the conflict manually may be necessary, just
as can very occasionally be necessary in other situations. In most cases,
however, an einfo explaining the situation should be sufficient, just as
it normally is with any other USE flag conflicts.
This should be the clearest from a user perspective, and should require
the minimal amount of package.use magic, yet it remains an option where a
user finds it necessary. There will be a bit of disruption when KDE4
ultimately stabilizes, but handled correctly, it shouldn't be any more of
a problem than any major version upgrade on a major desktop environment
would be -- that is, while some problems should be expected (and well
published in GWN and the like before stabilization), they should be
resolvable, and temporary.
--
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
--
gento...@gentoo.org mailing list
Dan Meltzer
> "Caleb Tennis" <ca...@gentoo.org> posted
> 34384.192.168.2.159...@www.aei-tech.com, excerpted below,
> on Wed, 21 Jun 2006 10:03:21 -0400:
>
> > [Stefan Schweizer wrote...]
> >> qt3 - enable optional qt3 support
> >> qt4 - enable optional qt4 support
> >
> > Maybe I just need a little time to warm up to this. :)
>
>
> This should be the clearest from a user perspective, and should require
> the minimal amount of package.use magic, yet it remains an option where a
> user finds it necessary. There will be a bit of disruption when KDE4
> ultimately stabilizes, but handled correctly, it shouldn't be any more of
> a problem than any major version upgrade on a major desktop environment
> would be -- that is, while some problems should be expected (and well
> published in GWN and the like before stabilization), they should be
> resolvable, and temporary.
>
>
When do you propose qt4 hits make.defaults? When kde4 hits p.mask,
when it hits ~arch, or when it hits arch?
I think mr_bones__ idea was the most appropriate thus far.
>
> --
> 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
>
> --
> gento...@gentoo.org mailing list
>
>
--
gento...@gentoo.org mailing list
Ryan Hill
> On Wed, Jun 21, 2006 at 05:20:47PM +0200, Carsten Lohrke wrote:
>> On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote:
>>> qt3 - enable optional qt3 support
>>> qt4 - enable optional qt4 support
>> That will be a mess to support in the long run.
>
> Why?
Ditto. Can anyone explain why this is bad?
I simply don't want QT 4 on my system at this time. Just like I don't want
GTK+-1 on my system. Already I've had to start adding packages to package.use
with -qt to avoid pulling in qt4 (right next to all my -gtk entries). I don't
see how it helps anyone to have a single 'qt' flag that changes meanings
depending on the package it's used with.
Dan Meltzer wrote:
> When do you propose qt4 hits make.defaults? When kde4 hits p.mask,
> when it hits ~arch, or when it hits arch?
When it hits arch I guess. KDE itself won't be affected by the flag since it's
not an optional dependency, and anyone building packages with optional KDE
support should be using the kde flag, not qt, so I don't really see how this is
relevant. But anyone building packages with optional KDE support will be
expecting them to work with the latest stable version.
--de.
Paul de Vrieze
>
> -qt +qt3:
>
> This would only be available in 2 cases:
>
> - Package supports both qt4 and qt3, and they're mutually exclusive
> - Package supports both qt4 and qt3, and they can both be enabled at once
>
> In case 1, "-qt +qt3" would enable qt3. In case 2, "-qt +qt3" would
> enable qt3.
>
> In other words, as I've been trying to say all along, there is no such
> thing as a preference flag here. That creates a 2-flag combination to
> get a single feature, which is _not_ what we want. There is a "qt" flag
> to indicate enabling the best available qt for that package, and there
> are "qt#" flags to indicate enabling older qt for that package.
>
> The downside to this setup is that it's difficult to avoid installing
> certain qt versions when it's unknown which version USE=qt will pull in
> for any given package. This favors an entirely versioned setup instead,
> and we should get rid of USE=qt altogether in favor of only USE=qt#.
Avoiding installation of a package can IMHO better be done by
using /etc/portage/package.mask
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: pau...@gentoo.org
Homepage: http://www.devrieze.net
Harald van Dijk
Arguably better, but sure not easier. It requires lots of entries in
/etc/portage/package.use since portage won't automatically disable the
qt flag if the required qt version is masked, and when packages change
from/to qt3 to/from qt4, there is no way for portage to let the user
know (so that "cat/pkg -qt" can be removed from package.use again).
--
gento...@gentoo.org mailing list