[maemo-developers] QT Packages, Repositories and PR1.2

[From: Attila Csipa]

On Thu, May 20, 2010 at 6:10 PM, Felipe Crochik <felipe at crochik.com> wrote:

> I thought the only difference was on where the libraries got installed.
> Isn't it? On a follow up question: Why do
>
the Qt applications have to "know" where the qt libraries are? Wouldn't be
> better/easier if they would look for the libraries first on the "starting"
> folder and then on the path or, at least, the path  on a "system variable"
> like "QT_PATH"? Hopefully my question is not too dumb or the answer too
> obvious... :)
>

Don’t forget that the incoming Qt version is NOT binary (nor source)
compatible, so you cannot just swap in new libs, you HAVE to use it with the
libs it was compiled with. Another requirement was parallel installs (very
atypical for Qt, as on desktops it IS generally binary backward compatible).


Isn't it a problem that someone can deploy a package with the same name of
> existing one "maintained" by someone else? I would think that it get very
> ugly if someone, even by mistake, put a new package on the repository that
> replaces an existing library... Let's say by mistake I come up with a
> package that is called libqt4-core with a version 4.7 and it is not remotely
> related to qt, wouldn't it break all the applications that depend on qt? I
> understand that probably such package would never make to the "extras"
> (someone would stop it on testing or development) but still seems a little
> too fragile and I assume a lot of users have the development catalog on and
> would not have how to know that was not a valid update.
>

AFAIK Packages present in the SDK or the core distribution are not
uploadable to extras-devel. The case you mention is possible only for user
packages, and we had no precedent for that (in fact, we had cases where
people took over orphaned packages).


>
> That being said isn't there an opportunity here for us to submit the qt
> source code to be compiled using what will be the pr 1.2 location, package
> name and version? Or even simpler upload the existing scratchbox deb files?
> Please let me know if I am missing something obvious here, I just haven't
> found why this could be a bad move... It seems a much better/safer solution
> than for instance adding the "nokia sdk" catalog like was suggested on the
> talk.maemo.org (http://talk.maemo.org/showthread.php?t=52442).
>

Nokia (the Trolltech people to be more precise) are the maintainers of the
Qt packages. I think it is a very bad idea to undertake public partisan
actions with their packages without the consent of the maintainers (though
it’s not illegal Qt being GPL and all). If anything, we should work together
to find acceptable solutions to everyone.


> Right now we have several applications that can't be installed because they
> were "linked" to the qt4-core 4.6 packages and we have a bunch of
> applications that will not follow the "testing" cycle and will have to be
> replaced just because their developers want to make them available to the
> current n900 and not have to wait for pr 1.2
>

But what would that solve ? The moment you have PR1.2 released, the devel
version of Qt will move to 4.7 (you can already download Qt4.7 packages from
qtlabs that replace libqt4-maemo5). All the cool kids will start coding with
4.7 features and you’ll have the same situation.  There will be always a
’next’ version devel people play with and end users drool for. Our ’real’
problem is that of Qt *4.5, the current stable version*, meaning you cannot
push 4.5 apps to testing/extras. 4.6 is still unreleased and unsupported as
far as Fremantle goes (that is why the whole PR1.2 SDK thing is irrelevant -
you can still build Qt4.5 apps, no changes there). The fact that 4.6 is
vastly superior for developing Fremantle friendly apps is a different matter
entirely.


>
> A different idea, probably even harder, would be to have lift the
> restrictions on the qt4-maemo5 packages and once pr 1.2 is out have the
> autobuilder recompile them after updating the references to the new qt
> libraries.
>
>
The packages are not just renamed, but also build-bumped, so there is no
compatibility guarantee (plus, the path magic you would have to do would
make things very error prone).

The current situation is frustrating to developers and even more to users. I
> can't imagine I am alone on this and would hate to see something that we can
> "fix" affect new applications being developed/ported to the n900 and/or
> scaring users away by not letting them get the applications they want.
>
>
We’re perfectly aware of this and agree that the situation is ’less than
ideal’ (talk about euphemism), but, to repeat myself, jumping over system
components without maintainer cooperation is NOT a good idea, either
technically or community-wise.


Best regards,
Attila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.maemo.org/pipermail/maemo-developers/attachments/20100520/d89dcbf5/attachment.htm>