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

From: Felipe Crochik felipe at crochik.com
Date: Thu May 20 19:10:49 EEST 2010
Attila,

Foreword: the Qt versioning mismatch problem is not strictly the consequence
> of the PR1.2 delay, it is mainly the result of the packaging choice of how
> Qt
> gets updated to newer versions.
>
>
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... :)


> > 1.    What happens if two people submit packages with the same name to
> the
> > "extras-development"?
>
> If they have literally the same same/versioning scheme, the second one will
> be
> rejected.
>

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.

> 3.    any other reason (legal, technical, ..) why one of us can't submit
> > the deb files to extras-devel? Would/could we upload them as non-free to
> > make easier?
>
> Extras-devel is not just a repository, it's a whole infrastructure. Using
> the
> autobuilder ensures adherence to certain standards, handling of source
> packages, the 'rebuildability', promotion, etc.
>
> I understand extras-devel is more than a repository. I have figured out
that the hard way trying to upload my first package there :)

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).

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

Even if it is a temporary solution and the applications will still have to
be recompiled after pr.1.2 it is no different than the current scenario and
would assure that the existing applications could continue to testing and
that users would be able to use them in the meanwhile. I don't even
understand how people can test applications that rely on the qt4-core 4.6
packages as now.

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 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.

Felipe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.maemo.org/pipermail/maemo-developers/attachments/20100520/1ed53a37/attachment.htm>
More information about the maemo-developers mailing list