Attila,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="gmail_quote"><div><div class="im">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></div></div></div></div></blockquote><div><br>Isn't the Qt version on PR 1.2 supposed to be 4.6.2 (the same we have on qt4-maemo5 and scratchbox right now)? I can't remember where I read this but it is my assumption. If not, them very little makes sense to me because the packages compiled by the autobuilder right now are being build against a qt version that is never going to be available - these packages would be even more useless them the ones compiled against the qt4-maemo5<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="gmail_quote">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></blockquote><div><br>Good to know that the "core" packages can't be changed like that. I recognize that is a good idea to have a different user take over a orphan package but I would feel better if it was not as simple as submitting a new package with the same name and higher version. Maybe a consent from the maintainer or at least a "put package on hold" for few days waiting for a reply (or lack of) from the maintainer to an email sent automatically from maemo informing of the change. As now, It all can happen too quickly, in less than a day someone can submit a package and this package will be available to the users that have the development catalog. Just my paranoid self talking... As the community grows it may become more important. <br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="gmail_quote"><br><div><div class="im">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></div></div></blockquote><div><br>I am not suggesting doing that despite them... I was actually hoping they would be around and help out... At the same time I know that they probably can't endorse this idea on Nokia's behalf or they would have done that already.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="gmail_quote">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></div></div></blockquote><div><br>The issue is not developing for an upcoming version. We will always have the scenario where there is a stable/official version and a upcoming one. Right now we have the qt4-core (4.5) and the qt4-maemo5 (4.6) in two different folders... Everything would be fine if the qt packages included with pr1.2 were the qt4-maemo5 once out they would simply replace the "beta" ones <br>
<br>I may be too naive but I think all this could be much simpler if we just had each official/major release of qt as a different package and installed to a different folder. Developers would be able to control the application dependencies. In fact that is exactly what I think my suggestion would do now. <br>
<br>By just having the scratchbox qt packages on the device everything would be good to go, for now, developers would be able to test the "beta" application against the "upcoming" qt release and worst case scenario after the upcoming release arrives they would generate a new version of their packages with different dependencies. Then the new 4.7 packages would have a different package name and be installed to a different location and we could start the dance all over again.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="gmail_quote"><div class="im"><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></div></div></blockquote><div><br></div></div>Again, I am not suggesting a rebellion ... Would be nice if any of the official "maintainers" (nokia, qt) could get involved on this discussion if nothing else as advisers. It just seems to be like a "inexpensive" solution to a big pain but they would know better about the unintended side effects.<br>
<br>Felipe<br>