Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 15:45, Donnie Berkholz wrote: -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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpmmr8DxgubS.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Fri, Jul 14, 2006 at 09:09:15PM +0200, Paul de Vrieze wrote: On Wednesday 21 June 2006 15:45, Donnie Berkholz wrote: -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 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). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, 20 Jun 2006 16:14:08 -0700 Donnie Berkholz [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Kevin F. Quinn wrote: On Tue, 20 Jun 2006 16:14:08 -0700 Donnie Berkholz [EMAIL PROTECTED] 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
середа, 21. червень 2006 03:46, Diego 'Flameeyes' Pettenò Ви написали: 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 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, 20 Jun 2006 23:25:42 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Kevin F. Quinn wrote: On Tue, 20 Jun 2006 16:14:08 -0700 Donnie Berkholz [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
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). 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... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
George Shapovalov wrote: середа, 21. червень 2006 03:46, Diego 'Flameeyes' Pettenò Ви написали: 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.. -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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Kevin F. Quinn wrote: 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 15:21, Caleb Tennis wrote: 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 ). Although I can see why you suggest this (Qt 4 is what should become mainline 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 lookfeel of a desktop, but that is marginally important. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUEQgyAF1ov.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, Jun 20, 2006 at 02:22:21PM -0700, Donnie Berkholz wrote: 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 [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgp9otDnjVXHu.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
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. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpr9mpgtI9J6.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, Jun 20, 2006 at 06:56:58PM +0200, 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. 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). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
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). -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpkdzlOIoCBy.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
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 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 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tuesday 20 June 2006 19:41, Simon Stelling wrote: 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 We're not talking about interfaces, but more likely bindings right now. 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? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpEmjST7FmsQ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Henrik Brix Andersen wrote: 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, 20 Jun 2006 14:22:21 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Henrik Brix Andersen wrote: 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. +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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Kevin F. Quinn wrote: 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On 6/20/06, Stefan Schweizer [EMAIL PROTECTED] 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. snip 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 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
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 stuff that most people don't care about and so can ignore), it shouldn't be that bad. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
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. 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. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgphRiuuiKxow.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Diego 'Flameeyes' Pettenò wrote: 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
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. But _that_ is what you asked me to say. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp0zdq01LWDL.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Diego 'Flameeyes' Pettenò wrote: 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 03:06, Donnie Berkholz wrote: 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. 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. 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? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpLqTDHv9L1n.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Diego 'Flameeyes' Pettenò wrote: 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On 6/20/06, Donnie Berkholz [EMAIL PROTECTED] wrote: 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 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
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? :) 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. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp1yqK7Ozpud.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Diego 'Flameeyes' Pettenò wrote: 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 signature.asc Description: OpenPGP digital signature
