<div class="gE iv gt"><table class="cf gJ" cellpadding="0"><tbody><tr><td class="gF gK"><table class="cf ix" cellpadding="0"><tbody><tr><td><br></td></tr></tbody></table></td><td class="gH"><br></td><td class="gH"><br></td>
</tr></tbody></table></div><div id=":v" class="ii
gt"><div class="gmail_quote"><div class="im">On Thu, May 20, 2010 at
6:10 PM, Felipe Crochik <span dir="ltr"><<a href="mailto:felipe@crochik.com" target="_blank">felipe@crochik.com</a>></span>
wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>I thought the only difference was on where
the libraries got installed. Isn't it? On a follow up question: Why do </div></div></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>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... :)<br>
</div></div></blockquote></div><div><br>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). <br>
<br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>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.</div>
</blockquote></div><div><br>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).<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div><br>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 <a href="http://talk.maemo.org/" target="_blank">talk.maemo.org</a> (<a href="http://talk.maemo.org/showthread.php?t=52442" target="_blank">http://talk.maemo.org/showthread.php?t=52442</a>).<br>
</div></div></blockquote></div><div><br>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.<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>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<br>
</div></div></blockquote></div><div><br>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 <b>4.5, the current stable version</b>, 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.<br>
<br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>
<br>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. <br>
</div></div><br></blockquote></div><div><br>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).<br><br>
</div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<br>
<br></blockquote></div><div><br>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.<br>
</div></div><br><br>Best regards,<br><font color="#888888">Attila</font><br></div><br>