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;">Foreword: the Qt versioning mismatch problem is not strictly the consequence<br>
of the PR1.2 delay, it is mainly the result of the packaging choice of how Qt<br>
gets updated to newer versions.<br>
<br></blockquote><br><div>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... :)<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;">
<br>
> 1. What happens if two people submit packages with the same name to the<br>
> "extras-development"?<br>
<br>
If they have literally the same same/versioning scheme, the second one will be<br>
rejected.<br></blockquote><div><br>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.<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;">
> 3. any other reason (legal, technical, ..) why one of us can't submit<br>
<div class="im">> the deb files to extras-devel? Would/could we upload them as non-free to<br>
> make easier?<br>
<br>
</div>Extras-devel is not just a repository, it's a whole infrastructure. Using the<br>
autobuilder ensures adherence to certain standards, handling of source<br>
packages, the 'rebuildability', promotion, etc.<br>
<br></blockquote><div>I understand extras-devel is more than a repository. I have figured out that the hard way trying to upload my first package there :) <br><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">talk.maemo.org</a> (<a href="http://talk.maemo.org/showthread.php?t=52442">http://talk.maemo.org/showthread.php?t=52442</a>).<br>
<br>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>
<br>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.<br>
<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>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>Felipe<br><br>