Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)
apaku at gmx.de
Thu Jul 8 20:42:23 CEST 2010
On 08.07.10 20:14:47, Maciej Mrozowski wrote:
> 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. So problem has been avoided as well (note that KDE SC
> 4.5.0 is not out yet and number of bug reported already is significant).
> 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".
And right-fully so, the packagers need to take care about this and
upgrade their Qt packages. Thats their job and only theirs. Thats not
> > 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)
People building from sources are expected to be able to follow upstream
updates for _everything_ they build themselves. $random_user doesn't
build stuff from sources (except very few things), they use packages at
which point packagers come into the game:
> - packager who prepared packages for them was not told Qt-4.6.2 is broken in
> this regard.
Then he shouldn't be a packager. Packagers are _expected_ to follow the
upstream of whatever they package and update the packages as soon as an
update is released (at least for bugfix releases). If they're not able
to do that they shouldn't create packages in the first place.
> 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).
Uhm, packagers are distro-people in most of the cases. So in case they
do ship KDE 4.5.x packages with Qt4.6.2 (or earlier) they'll get
bugreports and rightfully so. At that point its their job to find out whats wrong,
this may include filing a KDE bug and getting told "this is an upstream
problem, please report to Qt.
> And all of this could have been avoided if dependencies were raised in first
The compile time dependency is nonsense, KDE 4.5.x doesn't _need_ 4.6.3
to compile, it needs 4.6.x (x>=0). The problem is a pure _runtime_
problem and hence needs to be fixed at runtime. If KDE had a way of
requiring a certain Qt version during runtime, that requirement should
be changed. But changing a build-time requirement because of 1 bug that
occurs during runtime is just plain wrong.
> (and some people say it's distros that work like "it compiles -> release")
So? Thats broken distro's and broken packagers, we shouldn't need to
care about people not taking their "job" seriously.
Of course you have a purpose -- to find a purpose.
More information about the release-team