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
