Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)

Loïc Corbasson loic.corbasson at
Thu Jul 8 20:29:39 CEST 2010


2010/7/8 Maciej Mrozowski <reavertm at>

> On Thursday 08 of July 2010 19:28:01 Thiago Macieira wrote:
> > On Thursday 8. July 2010 18.42.36 Maciej Mrozowski wrote:
> > > The question is: who cares whether Qt minor releases are
> interchangeable
> > > or  not so that we can just specify minimal required dependencies to
> > > ensure only that stuff compiles?
> > >
> > > "the build-time dependency should only be a minor release of Qt " - is
> > > this  policy written anywhere? Why is it more important that code
> > > compiles than providing better user experience? I think it's
> fundamental
> > > question.
> >
> > The build-time requirement doesn't influence the run-time requirement of
> > Qt. You can compile against 4.6.3 and then run against 4.6.0.
> >
> > So requiring 4.6.3 to compile will NOT get your bug solved.
> I disagree but let me explain.
> Someone fetches KDE tarballs. Tries to build them - then encounters build
> error stating that Qt dependencies are not met. Person in question upgrades
> Qt, then builds KDE and problem has been solved by avoiding it.
> If person in question is distro packager, he does the same, but he also
> ensures that runtime dependencies of packages he's preparing are matching
> build time dependencies.
> Distro packager should know that he should upgrade to the latest version of
Qt 4.6 to get the latest fixes...

> If said person purposely hacks buildsystem to allow older Qt version - he
> should be ready to grab the pieces. The only case when bug is not "solved".
> > You need to convince your distro to upgrade. And all KDE has to do is to
> > say that distros should upgrade.
> >
> > And that should go without saying that distros should always upgrade. And
> > they do.
> >
> > So what are you complaining about?
> >
> > Bug reported -> ceck
> > Bug fixed -> check
> > Distros upgrading -> check
> Right. But those users who will go through this exact same procedure over
> and
> over AGAIN. Because:
> - they weren't told Qt-4.6.2 is broken in this regard (why would they? they
> just grab packages and build from source against whatever Qt version they
> happen to have)

I feel that these are quite specific users you're talking about. People not
upgrading Qt and building their software themselves. I suppose that if they
are in that specific combination they somehow know what they're doing -- no?

> or
> - packager who prepared packages for them was not told Qt-4.6.2 is broken
> in
> this regard.

... because it's a Qt bug and the Qt packager should upgrade its package as
he is following the changelogs of the software he packages -- no?

> So the only reliable way for them to find out is to personally experience
> bug,
> fill it (or seach bugzilla first), then be told to go away and complain
> elsewhere (usually distro).
> And all of this could have been avoided if dependencies were raised in
> first
> place.
> And some people don't care about bugs for system tray notifications,
because they don't use them. Each new 4.6 version of Qt will fix bugs,
should we make it mandatory to upgrade for anyone wanting to use KDE? I
don't feel so. People who want fixed bugs upgrade. Others probably don't
care, whatever the reason behind this might be (maybe just because they
don't want to recompile everything just for something they're not using?).
Compile-time is for compilation-related checks.

> (and some people say it's distros that work like "it compiles -> release")
> Now, it's been enough noise already so most distro packagers are probably
> aware that current Qt dependencies for 4.5 are not what's supposed to be
> used
> actually, but there will always be people building from source manually.
> And they probably (should) know what they're doing.

> cheers
> --
> Maciej Mrozowski
> Gentoo KDE release coordinator
> Loïc Corbasson
[loic.corbasson at]
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the release-team mailing list