[gentoo-dev] Re: Re: [RFC] Useflags: qt, qt3, qt4?
On Wed, 21 Jun 2006, Carsten Lohrke wrote: On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote: 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. 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. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: [RFC] Useflags: qt, qt3, qt4?
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. 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. :) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: [RFC] Useflags: qt, qt3, qt4?
Caleb Tennis [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: [RFC] Useflags: qt, qt3, qt4?
On 6/21/06, Duncan [EMAIL PROTECTED] wrote: Caleb Tennis [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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. :) [snip] 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 -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
