Re: [gentoo-dev] RFC: qt.eclass
On Saturday 02 July 2005 22:54, Caleb Tennis wrote: While your proposal works okay for the qt4 scenario, I'm more concerned with the existing qt3 at the moment. As is, I stil l don't see a way around what has been proposed for those ebuilds. Until portage has the ability to handle deps, I fear there's no real way around it. I don't think we'll have time to wait much longer; I expect ebuilds that need qt4 will start appearing in portage soon and the minute that qt4 is marked ~arch it instantly creates the dependency mess addressed previously. We can start porting those ebuilds that just need to be changed using =x11-libs/qt-3*. Then we can change kde-functions.eclass for the ebuilds using need-qt() (which can set something like e.g. || ( =x11-libs/qt-3.3* ... =x11-libs/qt-3.1* ) ); and finally we can deal with the remaining ebuilds (not many probably) using the qt.eclass (or qt3.eclass, or qt3-info.eclass, or whatever), or again something like || ( =x11-libs/qt-3.3* ... =x11-libs/qt-3.1* ) ) where possible. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Thursday 30 June 2005 19:54, Caleb Tennis wrote: (I'd like to hear your thoughts and comments on the matter below before I start the process of changing ebuilds to comply.) With Qt4 entering portage, we are going to start running into a dependency problem with ebuilds that do: DEPEND==x11-libs/qt-3.2 Because Qt4 satisfies this depend even though it's not compatible. Enter my proposed qt.eclass (which also replaces kde-functions.eclass for people who are using it strictly for Qt). Now you can: inherit qt DEPEND=$(qt_min_version 3.0) or DEPEND=qt? ( $(qt_min_version 3.1.2-r2) ) And the eclass will expand out all Qt3 ebuilds which satisfy the statement. If you don't need anything this fancy (that is, if the ebuild will work with any Qt3 version), then the eclass isn't necessary; just change the ebuild to: DEPEND=x11-libs/qt-3* As an added bonus, you get an exported pkg_setup function which will handle some of the same checks that were handled via kde-functions. Thanks, Caleb I'm back from a trip and I'm slowly catching up with all the mails on this topic, but a couple of things come to my mind ... please bear with me. First, a new eclass for Qt4 ebuilds should really be called qt4.eclass, with another one, qt3.eclass, to be used to port the current Qt3-based ebuilds. Dealing with more than one major version in a single eclass is a pain; this is mostly true for the kde eclasses, but still applies to Qt. In fact, we need to introduce a new clean eclass for KDE4-based applications, so starting from scratch with a kde4.eclass and a qt4.eclass makes a lot of sense. As many already pointed out, using something like DEPEND=$(qt_min_version 3.1) is very ugly, so we should use it only if it is really unavoidable. There is also another consideration to do: many Qt applications, or applications with optional Qt support, are not maintained by the qt/kde herd. We had many problems in the past because it was not easy at all to write ebuilds for these applications, this time we should make this task as intuitive as possible. There was a lot of discussion internally already with particular focus on the kde eclasses, but the problems for Qt and KDE applications are nearly the same so designing a new qt eclass uncovers the same problems. Among the options discussed, I particularly like the following one (I think something like this also showed up in this thread, too): An application based on Qt4 should look just like this: inherit qt4 HOMEPAGE=... SRC_URI=... ... the qt4 eclass would automatically add a DEPEND==x11-libs/qt-4*, and would provide default src_compile(), src_install()... For the applciations (5% ?) that require an higher version of Qt, the ebuild should look like: NEED_QT=4.1 inherit qt4 HOMEPAGE=... SRC_URI=... ... the qt4 eclass would insert the right line in DEPEND. For applications with optional Qt support, the ebuild could manually set the dependency on x11-libs/qt; it is enough to ship a qt4-info.eclass that provides useful functions, with qt_min_versions() among them. So an ebuild with optional Qt support could be like inherit qt4-info HOMEPAGE=... SRC_URI=... DEPEND=qt? ( =x11-libs/qt-4* ) ... (I think this would be the case for 99% of the ebuilds) or inherit qt4-info HOMEPAGE=... SRC_URI=... DEPEND=qt? ( $(qt_min_version 4.1.2) ) ... if there's absolutely no other way to do it. This proposal is meant for Qt, but it should be read as a proposal for both Qt and KDE: we can have a kde4.eclass and a kde4-info.eclass that work in the same way. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Saturday 02 July 2005 22:09, Dan Armak wrote: On Saturday 02 July 2005 22:41, Gregorio Guidi wrote: [...] An application based on Qt4 should look just like this: inherit qt4 HOMEPAGE=... SRC_URI=... ... [...] This proposal is meant for Qt, but it should be read as a proposal for both Qt and KDE: we can have a kde4.eclass and a kde4-info.eclass that work in the same way. I know you know this, but for other readers, this is exactly the design of the current kde.eclass+kde-functions.eclass :-) At least it was until they gathered up a huge amount of special cases and backward support. Exactly, in fact this should be reassumed also as kde eclass started from scratch, without the evil need-kde() :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Saturday 02 July 2005 14:41, Gregorio Guidi wrote: I'm back from a trip and I'm slowly catching up with all the mails on this topic, but a couple of things come to my mind ... please bear with me. First, a new eclass for Qt4 ebuilds should really be called qt4.eclass, with another one, qt3.eclass, to be used to port the current Qt3-based ebuilds. Dealing with more than one major version in a single eclass is a pain; this is mostly true for the kde eclasses, but still applies to Qt. In fact, we need to introduce a new clean eclass for KDE4-based applications, so starting from scratch with a kde4.eclass and a qt4.eclass makes a lot of sense. I completely agree. As many already pointed out, using something like DEPEND=$(qt_min_version 3.1) is very ugly, so we should use it only if it is really unavoidable. I agree too, but I haven't seen yet how it can be avoided. An application based on Qt4 should look just like this: inherit qt4 HOMEPAGE=... SRC_URI=... ... the qt4 eclass would automatically add a DEPEND==x11-libs/qt-4*, and would provide default src_compile(), src_install()... That's fine, except I would think that very few ebuilds would be able to make use of a default src_compile() and src_install(). It works for the kde eclass because most of the kde packages are built using the standard kde auto* scripts, but I doubt many qt only packages have the same build structure. [snip] While your proposal works okay for the qt4 scenario, I'm more concerned with the existing qt3 at the moment. As is, I stil l don't see a way around what has been proposed for those ebuilds. Until portage has the ability to handle deps, I fear there's no real way around it. I don't think we'll have time to wait much longer; I expect ebuilds that need qt4 will start appearing in portage soon and the minute that qt4 is marked ~arch it instantly creates the dependency mess addressed previously. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Friday 01 July 2005 11:55, Chris Bainbridge wrote: On 30/06/05, Olivier Crete [EMAIL PROTECTED] wrote: On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote: I'm sorry, yes, that's what I do in this case. Also, the eclass is in portage if anyone is so inclined to see how harmless it really i Why not just use =qt-3.3 since qt3 probably wont have any new major release ? This would seem like the easiest option. Is there any reason not to do it this way? Sometimes we need to specify a minimal version or revision because something depends on specific fixes made there and needs to force a qt upgrade. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpX6M6iKO26J.pgp Description: PGP signature
Re: [gentoo-dev] RFC: qt.eclass
Caleb Tennis wrote: snip 2. You'll force a user to upgrade to qt 3.3 if they attempt to install any package that depends on Qt. Speaking from personal experience, I still have some servers using Qt 3.1 because I have programs running 24/7 that rely on Qt and simply cannot be upgraded right now. You don't force anyone to do anything. If they don't want to upgrade because they can't then they can p.mask the programs they can't upgrade. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Friday 01 July 2005 10:35 am, Alec Joseph Warner wrote: You don't force anyone to do anything. If they don't want to upgrade because they can't then they can p.mask the programs they can't upgrade. But this isn't about upgrading Qt, it's about the packages that depend on it. If you change deps from =qt-3.0 to =qt-3.3 then nobody will be able to work with a Qt dependant package until they upgrade Qt. In the same regard, there are people still using Apache1 whom we aren't forcing to upgrade to Apache2 just so they can use some of the apache modules. Also, another downside to the =qt-3.3 approach is that it doesn't cleanly handle the cases of =qt-3.3.2-r1. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Caleb Tennis wrote: DEPEND=$(qt_min_version 3.0) or DEPEND=qt? ( $(qt_min_version 3.1.2-r2) ) And the eclass will expand out all Qt3 ebuilds which satisfy the statement. I'm no expert on portage, but running random functions in DEPEND sounds like a bad idea. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCxEDRXVaO67S1rtsRAvggAKDQ+Tpj6vywLVTFJ2vHqnLc0GH2jQCg6znN p3amuxI6r84tb2dNOK5PmBo= =Qvpf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Thursday 30 June 2005 02:58 pm, Donnie Berkholz wrote: Caleb Tennis wrote: DEPEND=$(qt_min_version 3.0) or DEPEND=qt? ( $(qt_min_version 3.1.2-r2) ) And the eclass will expand out all Qt3 ebuilds which satisfy the statement. I'm no expert on portage, but running random functions in DEPEND sounds like a bad idea. it depends on the information that the function acts upon ... if the results depend on stuff that is installed (i.e. things in /var/db/pkg) or env vars the user manipulates (like $SOME_FOO), then that's bad ... if the results depend on a variable that changes across ebuilds but retains the same value in a specific ebuild (like $PN or $PV), that is OK -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Thursday 30 June 2005 02:15 pm, Mike Frysinger wrote: it depends on the information that the function acts upon ... if the results depend on stuff that is installed (i.e. things in /var/db/pkg) or env vars the user manipulates (like $SOME_FOO), then that's bad ... if the results depend on a variable that changes across ebuilds but retains the same value in a specific ebuild (like $PN or $PV), that is OK -mike This function doesn't rely on anything that isn't directly within the eclass itself - ie, a static list of all of the Qt versions over the ages. No files on the system or environment variables at all. Caleb -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Thursday 30 June 2005 03:01 pm, Thomas de Grenier de Latour wrote: It seems that portage evaluates disjonction left to right and stops on the first match it founds. Thus, if you want want it to choose the best matching version, you should rather sort them in decreasing order. (At least, that's what a small test with CVS HEAD shows here.) I'm sorry, yes, that's what I do in this case. Also, the eclass is in portage if anyone is so inclined to see how harmless it really is. Caleb -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote: On Thursday 30 June 2005 03:01 pm, Thomas de Grenier de Latour wrote: It seems that portage evaluates disjonction left to right and stops on the first match it founds. Thus, if you want want it to choose the best matching version, you should rather sort them in decreasing order. (At least, that's what a small test with CVS HEAD shows here.) I'm sorry, yes, that's what I do in this case. Also, the eclass is in portage if anyone is so inclined to see how harmless it really i Why not just use =qt-3.3 since qt3 probably wont have any new major release ? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
