Bugzilla Bug 217161

Split Qt 4.4.0_rc1 has just been added to the tree under package.mask.
x11-libs/qt-4.4.x is only a meta package which nothing should depend upon
directly. Before we unleash it on ~arch we would prefer for all packages that
depend on things like e.g. =x11-libs/qt-4* or $(qt4_min_version 4.2) to have
their dependencies updated. Typically the updated dependencies would look like
e.g.:

DEPEND="|| ( ( x11-libs/qt-fooA:4  x11-libs/qt-fooB:4 )
               >=x11-libs/qt-4.2:4 )"

Where fooA and fooB are the split qt packages it requires. To use the SLOT
dependencies EAPI="1" is required before inheriting any eclasses.

We plan to get rid of the atrocity that qt4_min_version is, so starting from
the Qt 4.4.0 release, we won't be updating the list of versions is spews out,
anymore. Please stop using it.

Hello,

I don't understand why you intend in making qt release candidate at ~arch, why
not wait for release? It would be difficult for people to update into none
stable core package.

Hi folks,

Here's my question: you advised not to directly depend on x11-libs/qt-4.4.x
However, this causes my system to not have it installed at all (only
the individual x11-libs/qt-fooA:4 packages). This, in turn causes the 
qt4.ebuild to fail in line 89, i.e.

QT4_BEST_VERSION="$(best_version =x11-libs/qt-4*)

causing QT4_BUILT_WITH_USE_CHECK to fail as well. Is there something
I am missing?

Thanks,
Markus

(In reply to comment #2)
> Hi folks,
> 
> Here's my question: you advised not to directly depend on x11-libs/qt-4.4.x
> However, this causes my system to not have it installed at all (only
> the individual x11-libs/qt-fooA:4 packages). This, in turn causes the 
> qt4.ebuild to fail in line 89, i.e.
> 
> QT4_BEST_VERSION="$(best_version =x11-libs/qt-4*)
> 
> causing QT4_BUILT_WITH_USE_CHECK to fail as well. Is there something
> I am missing?
> 
> Thanks,
> Markus
> 

I'll fix that asap, thanks. :)

Thanks much, I appreciate it!

Best,
Markus

(In reply to comment #1)
> Hello,
> 
> I don't understand why you intend in making qt release candidate at ~arch, why
> not wait for release?

That's the plan actually, we do have to get dependencies fixed before we can
unmask it. While the _rc1 seems rather solid, we'll wait for the release to
unmask anything, there're still a few FIXMEs left in the ebuilds..

(In reply to comment #0)

> DEPEND="|| ( ( x11-libs/qt-fooA:4  x11-libs/qt-fooB:4 )
>                >=x11-libs/qt-4.2:4 )"

Please everybody be aware that the above example is subtly misleading. It might
lead your package manager into believing that you'd really be okay with having
x11-libs/qt-4.4:4 installed, but that's just a meta package, which would
satisfy the dependencies, but at considerable cost in compilation time.
In most (all?) cases the syntax should go like this:
DEPEND="|| ( ( x11-libs/qt-fooA:4  x11-libs/qt-fooB:4 )
               =x11-libs/qt-4.3*:4 )"

(In reply to comment #2)
> Here's my question: you advised not to directly depend on x11-libs/qt-4.4.x
> However, this causes my system to not have it installed at all (only
> the individual x11-libs/qt-fooA:4 packages). This, in turn causes the 
> qt4.ebuild to fail in line 89, i.e.
> 
> QT4_BEST_VERSION="$(best_version =x11-libs/qt-4*)
> 
> causing QT4_BUILT_WITH_USE_CHECK to fail as well. Is there something
> I am missing?

This should be fixed by this commit:

"zlin * gentoo-x86/eclass/qt4.eclass: Try to handle all flags in
QT4{,_OPTIONAL}_BUILT_WITH_USE properly for split qt to avoid duplicating the
same code in pkg_setup in lots of ebuilds. See bugs #217161 and #229193."

http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/qt4.eclass?r1=1.43&r2=1.44

(In reply to comment #6)
> > DEPEND="|| ( ( x11-libs/qt-fooA:4  x11-libs/qt-fooB:4 )
> >                >=x11-libs/qt-4.2:4 )"
> 
> Please everybody be aware that the above example is subtly misleading. It
> might lead your package manager into believing that you'd really be okay with
> having x11-libs/qt-4.4:4 installed, but that's just a meta package, which
> would satisfy the dependencies, but at considerable cost in compilation time.
> In most (all?) cases the syntax should go like this:
> DEPEND="|| ( ( x11-libs/qt-fooA:4  x11-libs/qt-fooB:4 )
>                =x11-libs/qt-4.3*:4 )"

This sucks when a package works with both 4.1, 4.2 and 4.3. It becomes
completely unmaintainable when a package needs >= -4.2.3-r7:4. When this bug
has been fixed there is no reason for the meta ebuild to exist at all. So just
ignoring it till this bug is fixed and removing the meta ebuild afterwards
seems more appealing in my opinion. We did consider this issue before writing
comment 0.

This split is making my built_with_use checks really ugly...

    confutils_require_built_with_all =x11-libs/qt-4* gif jpeg mysql opengl \
        png tiff

becomes a serious explosion of checks to work with <qt-4.4 and >=qt-4.4. Any
suggestions on making this nicer are welcome

(In reply to comment #9)
> This split is making my built_with_use checks really ugly...
> 
>     confutils_require_built_with_all =x11-libs/qt-4* gif jpeg mysql opengl \
>         png tiff
> 
> becomes a serious explosion of checks to work with <qt-4.4 and >=qt-4.4. Any
> suggestions on making this nicer are welcome

After comment #7 QT4_BUILT_WITH_USE_CHECK="gif jpeg mysql opengl png tiff"
should handle this properly for both monolithic and split packages as long as
you take care of setting the dependencies properly. gif, jpeg, png and tiff
will pull in qt-gui. mysql will pull in qt-sql and opengl will pull in
qt-opengl. Reading the new qt4_monolithic_to_split_flag() function would tell
you this.

Chipping in here, as the whole repository is broken wrt. Qt 4.4, even in the
cases ebuilds are using split ebuilds (incorrectly).

Beforehand: Relying on best_version() or the broken qt4_min_version() stuff
from qt4.eclass is not fine.


- Migrating existing ebuilds requires a dependency like 

|| ( ( splitQt1 .. splitQtN )  <x11-libs/qt-4.4:4 )

For x11-libs/qt any dependency atom _not_ including version 4.4 is fine. It is
a requirement¹ to list the split Qt ebuilds first.

- When Qt 4.4 is in testing, new ebuilds to be added to the tree may not
include x11-libs/qt. Depend on the split ebuilds only.

- For all ebuilds which are not tested or supposed to work with split Qt 4.4
ebuilds change the dependency to <x11-libs/qt-4.4:4 or a comparable dependency
atom, please.


The split Qt ebuilds are:

x11-libs/qt-assistant
x11-libs/qt-core
x11-libs/qt-dbus
x11-libs/qt-demo
x11-libs/qt-embedded
x11-libs/qt-gui
x11-libs/qt-opengl
x11-libs/qt-phonon
x11-libs/qt-qt3support
x11-libs/qt-script
x11-libs/qt-sql
x11-libs/qt-svg
x11-libs/qt-test
x11-libs/qt-webkit
x11-libs/qt-xmlpatterns


[1] https://bugs.gentoo.org/show_bug.cgi?id=232246

After going through the tree and fixing existing split Qt dependencies, my
script spits out these packages without any ebuild featuring split Qt ebuilds:

app-backup/bacula
app-crypt/ophcrack
app-crypt/xca
app-text/djvu
dev-ada/qtada
dev-java/qtjambi
dev-ruby/qt4-qtruby
dev-util/crossvc
media-libs/amanith
media-sound/mumble
media-sound/murmur
media-tv/mythtv
net-im/skype
net-irc/kvirc
net-misc/vidalia
net-wireless/wpa_supplicant
sci-chemistry/avogadro
x11-misc/qterm
x11-themes/mythtv-theme

Reading changelogs telling me to come here, I fail to see why such a change is
needed and why the old one is claimed as broken:
-COMMONDEPEND="|| ( ( x11-libs/qt-gui x11-libs/qt-core ) >=x11-libs/qt-4.2.0:4
)
+COMMONDEPEND="|| ( ( x11-libs/qt-gui x11-libs/qt-core ) =x11-libs/qt-4.3*:4 )

Please fix your scripts or try to rethink about it, because in both cases of
the || there would have been enough deps installed.