QT Packages, Repositories and PR1.2

I am trying to understand why we can't just upload the qt 4.6 deb files used
by scratchbox to "extras-development" so anybody can easily have access to
applications developed using qt4.6. I understand that maybe some of the new
"standard" qt4.6 may not work until PR1.2 is out but I haven't seen any
actual reports of anything that doesn't work or works worst than the current
qt4-maemo5 version.



Right now, as far as I can tell:

- If you use the "old" standard 4.5.3 packages you can't use the
new 4.6 features including the maemo5 lib.

- If you use the new "standard" 4.6 packages the users won't be
able to install on their devices because they won't have the qt 4.6 until PR
1.2 is out.

- If you use qt4-maemo5 packages your application will be blocked
from moving to testing and we will have to submit new packages once PR1.2 is
out.



Am I correct on this summary?



I saw a thread on talk.maemo.org about adding the repository used by the qt
sdk to get the new qt4.6 but it is very dangerous for most users.



Can anybody help me find the answer to these questions?



1. What happens if two people submit packages with the same name to the
"extras-development"?
2. What happens if a package with the same name exists on different
repositories?
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?



I assume that the package dependencies use the package name and version so
if we preserve the qt packages names once PR1.2 is out we would not have any
issues. in fact people would not even have to update them until a new
version is out.



Felipe

Hi Felipe!

On Thu, May 20, 2010 at 4:26 PM, Felipe Crochik <felipe@crochik.com> wrote:
> I am trying to understand why we can’t just upload the qt 4.6 deb files used
> by scratchbox to “extras-development” so anybody can easily have access to
> applications developed using qt4.6

These are packages used by scratchbox.
http://repository.maemo.org/pool/fremantle/free/q/qt4-x11/

>  I understand that maybe some of the new
> “standard” qt4.6 may not work until PR1.2 is out but I haven’t seen any
> actual reports of anything that doesn’t work or works worst than the current
> qt4-maemo5 version.
>
>
>
> Right now, as far as I can tell:
>
> -          If you use the “old” standard 4.5.3 packages you can’t use the
> new 4.6 features including the maemo5 lib.
>
> -          If you use the new “standard” 4.6 packages the users won’t be
> able to install on their devices because they won’t have the qt 4.6 until PR
> 1.2 is out.
>
> -          If you use qt4-maemo5 packages your application will be blocked
> from moving to testing and we will have to submit new packages once PR1.2 is
> out.
>
Well, testing is blocked, that's true.
>
> Am I correct on this summary?
>
>
>
> I saw a thread on talk.maemo.org about adding the repository used by the qt
> sdk to get the new qt4.6 but it is very dangerous for most users.
>
>
>
> Can anybody help me find the answer to these questions?
>
>
>
> What happens if two people submit packages with the same name to the
> “extras-development”?
> What happens if a package with the same name exists on different
> repositories?
> 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?
>
>
>
> I assume that the package dependencies use the package name and version so
> if we preserve the qt packages names once PR1.2 is out we would not have any
> issues… in fact people would not even have to update them until a new
> version is out.
>
>
>
> Felipe
>
>
>

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.

On Thursday 20 May 2010 15:26:46 Felipe Crochik wrote:
> - If you use the "old" standard 4.5.3 packages you can't use the
> new 4.6 features including the maemo5 lib.
> - If you use the new "standard" 4.6 packages the users won't be
> able to install on their devices because they won't have the qt 4.6 until
> PR 1.2 is out.
> - If you use qt4-maemo5 packages your application will be blocked
> from moving to testing and we will have to submit new packages once PR1.2
> is out.
>
> Am I correct on this summary?

Correct.

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

> 2. What happens if a package with the same name exists on different
> repositories?

The highest versioned one will get installed. If the versions are the same, it
shouldn't matter which one are you downloading from (i.e. if it matters, the
situation is FUBAR anyway).

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


Regards,
Attila

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

On Thu, May 20, 2010 at 6:10 PM, Felipe Crochik <felipe@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

Attila,

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


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

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.


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

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.


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

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

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.

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.


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

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.

Felipe

On 5/20/10, Felipe Crochik
<felipe@crochik.com<h/1tqlt06b4so7k/?v=b&cs=wh&to=felipe@crochik.com>>
wrote:
> 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

No way of knowing until PR1.2 actually hits the streets. The version
in the SDK *is* newer than the libqt4-maemo5 one (note - it is the
same base qt version, 4.6.2, but contains additional fixes/changes).
Note that the PR might touch on other things, too - for example the
4.6 on PR1.1 does not support autorotation, has hildon banner coloring
issues, etc. So there are things that work or look differently even
with the same Qt version.

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

I will talk about this to maemo.org people to see what the options are.

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

Now we're gettingto the crux of the matter. The choice is not to
support all versions of Qt simultaneously, but to have a single base
version for each PR, and have this version on the NAND for speed
reasons IIUC (plus integration issues as mentioned above) - and also
to lower memory footprint, having GTK+ and Qt simultanously is
stressful enough, having multiple versions of Qt in memory would make
things even worse. So you won't have Qt4.5 on PR1.2, no Qt4.6 in the
PR that will hopefully bring us Qt4.7, etc. The devel version is there
just for, well, development and testing. As you can see this
significantly lowers our maemo.org maneuvering space, too...

Best regards,
Attila

Now we're gettingto the crux of the matter. The choice is not to
support all versions of Qt simultaneously, but to have a single base
version for each PR, and have this version on the NAND for speed
reasons IIUC (plus integration issues as mentioned above) - and also
to lower memory footprint, having GTK+ and Qt simultanously is
stressful enough, having multiple versions of Qt in memory would make
things even worse. So you won't have Qt4.5 on PR1.2, no Qt4.6 in the
PR that will hopefully bring us Qt4.7, etc. The devel version is there
just for, well, development and testing. As you can see this
significantly lowers our maemo.org <http://maemo.org/> maneuvering space,
too...



I guess I finally "got" your point. Anything that you want to have end users
actually using you should develop on the "current stable" version. Anything
you develop that uses a "newer/upcoming" version it is just for you as a
developer and you will have to jump some hoops in order to test it. Once the
new release is official you publish your application again to be compiled
against the latest official/stable libraries.



The good news: I officially quit on trying to push the "new qt" libraries to
the device for "regular users".



The bad news now I have more questions:

1. As today what a developer needs to do to get an application that
uses qt to the end user? Is there a way to tell the autobuilder to compile
against the 4.5 qt and make the package only depend on it?
2. What is the point of the (not so few) qt applications on the
repository that were compiled against the qt4-core (4.6)? Unless pr1.2 will
have a qt that is binary compatible to the libs on the autobuilder right now
these packages will be completely useless, right? I thought the point of
committing packages using qt4-core (4.6) now was to have them ready for day
one when pr 1.2. gets out.
3. The qt applications not using qt4-maemo5 are "moved" to testing. How
are they being tested right now? They can't be tested on the pr1.1, because
they are compiled against qt 4.6. Are they not being tested at all
(everything is at halt); or they are being tested by people that have "pre
release" pr1.2; or are they being tested using scratchbox environment?



Thanks for taking the time to answer me. It has been very interesting and
"illuminating"



Best Regards,

Felipe

On Fri, May 21, 2010 at 2:42 AM, Felipe Crochik <felipe@crochik.com> wrote:

> As today what a developer needs to do to get an application that uses qt to
> the end user? Is there a way to tell the autobuilder to compile against the
> 4.5 qt and make the package only depend on it?

The developer should wait for pr 1.2. At this point in time all the
work spent on dealing with PR1.1 is wasted effort.

--
Ville M. Vainio
http://tinyurl.com/vainio

Dnia piątek, 21 maja 2010 o 07:06:35 Ville M. Vainio napisał(a):
> On Fri, May 21, 2010 at 2:42 AM, Felipe Crochik <felipe@crochik.com> wrote:
> > As today what a developer needs to do to get an application that uses qt
> > to the end user? Is there a way to tell the autobuilder to compile
> > against the 4.5 qt and make the package only depend on it?
>
> The developer should wait for pr 1.2. At this point in time all the
> work spent on dealing with PR1.1 is wasted effort.

Which means that whole work spent on dealing with Maemo is also wasted. Nokia
wants to be good at scarying developers out of platform?

Regards,
--
JID: hrw@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz