Re: QT Packages, Repositories and PR1.2

[ianaré sévi]

Le 22 mai 2010 06:15, Benoît HERVIER  a écrit :
>>I'll wait a little longer for this to get resolved, but if it takes
>>too long I just might ebay my n900 and go Android.
>
> You can also compile it yourself and create your own repository ...
> easier to manage, and do the trick ... and switch back to the maemo
> repository again when everythings will be fixed.
>

I've already made packages available through the garage, but there are
several problems with doing this :

* No way to promote packages past extras-devel.

* Asking non-technical users to start adding repos should be
discouraged due to security and stability issues. Having a community
reviewed repo is a great thing, if it actually worked as intended.

* I don't want users to have to look through the web to install an
app, it should be listed in the phone's manager.

* Fragmenting apps is a sure way to lose out against iPhone and
Android which do have centralized app managers.

Granted, deployment is not stopped, but going out of our way as
developers to also be package managers is a little silly IMO. Nokia's
expertise as a hardware maker but not a software publisher has been
showing itself lately ...

- ianaré sévi
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

RE: QT Packages, Repositories and PR1.2

[Felipe Crochik]

Attila,

> Hate to be the bearer of bad news :( What we managed to agree for the
PR1.2 release is that development releases starting with PR1.2 will not be
called libqt4-maemo5 as it's not that obvious that it's *really* just a
version for testing, prone to breakage and not necessarily the exact one
that will end up in the next PR. Future releases will sport the
'experimental' moniker (f.e. libqt4-experimental, python-qt4-experimental)
so it's more clear that it (and stuff depending on it) are not meant to be
promoted to end users. Not ideal, but hopefully will reduce confusion until
a better solution is found that is acceptable for both Nokia and the
community.

I started this subject after reading the post by Venemo
(http://talk.maemo.org/showthread.php?t=52442) so I decided that a good way
to close it would be to add a post there (page 4). 

Having threads like that "out in the open" and "our" exchange of emails
remind me of why I wanted the n900 so badly. It is a pretty unique device
and even more unique community. I hope "we" can manage to make it more of a
"mass market" product so nokia can justify maintaining it but, at the same
time, I would hate to have to give in this "geek" feeling to it. 

Thanks again, 
Felipe

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Benoît HERVIER]

>I'll wait a little longer for this to get resolved, but if it takes
>too long I just might ebay my n900 and go Android.

You can also compile it yourself and create your own repository ...
easier to manage, and do the trick ... and switch back to the maemo
repository again when everythings will be fixed.

-- 
Benoît HERVIER, Khertan Software - http://khertan.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[ianaré sévi]

This whole thing has been horrible from the start. I was happily
coding, learning to use Qt in a mobile environment, and then the
autobuilder got switched to a version NO ONE has on their phone. I can
build my app locally and it will run great on my n900, but as soon as
I download it from extras-devel, it seg faults. So I thought I would
wait until PR 1.2 was released, which was supposed to be '2 weeks' ...
now it's not coming until November ?!?!

It's obviously not working right (there are several apps that I use
that are un-updatable or now crash), is causing a lot of bad press,
frustrating developers, and making users confused and angry.

Please put up a wiki page detailing EXACTLY what needs to be done for
a package to work properly using the new autobuilder, if that is even
possible. Otherwise -- please, please please just put it back the way
it was. Just make it work.

I'll wait a little longer for this to get resolved, but if it takes
too long I just might ebay my n900 and go Android.

Sorry for the rant but sometimes it feels good to get things off your chest !

Cheers,

- ianaré sévi



2010/5/21 Attila Csipa :
> On Friday 21 May 2010 01:42:43 you wrote:
>> 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?
>
> In theory you just depend on the proper version of libqt4-dev, but it's tricky
> as you might indirectly reference libs that are also newer in the SDK/new PR
> so end up with a 4.6 dependency (or broken build), see below...
>
>> 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.
>
> Most of the applications got compiled for Qt4.6 'by accident', in terms that
> they do not really depend on or need 4.6 (nor did the original author WANT
> that specific version), but with current SDK setup they end up being linked
> against 4.6 anyway. This is why in my previous post I said this is not
> strictly a PR1.1 problem, a similar situation might arise with other packages
> if not managed correctly.
>
>> 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?
>
> AFAIK it's halted. Considering PR1.2 uses a separate repo, it makes no sense
> to promote them (yet) anyway. I would not consider prerelease 1.2 as a valid
> platform for community QA purposes.
>
>> Thanks for taking the time to answer me. It has been very interesting and
>> "illuminating"
>
> Hate to be the bearer of bad news :( What we managed to agree for the PR1.2
> release is that development releases starting with PR1.2 will not be called
> libqt4-maemo5 as it's not that obvious that it's *really* just a version for
> testing, prone to breakage and not necessarily the exact one that will end up
> in the next PR. Future releases will sport the 'experimental' moniker (f.e.
> libqt4-experimental, python-qt4-experimental) so it's more clear that it (and
> stuff depending on it) are not meant to be promoted to end users. Not ideal,
> but hopefully will reduce confusion until a better solution is found that is
> acceptable for both Nokia and the community.
>
>
> Regards,
> Attila
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Yves-Alexis Perez]

On 21/05/2010 09:34, Ville M. Vainio wrote:
> No, it means PR1.2 will probably happen sooner than you think.

And we've never been so close to the release!
-- 
Yves-Alexis
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Attila Csipa]

On Friday 21 May 2010 01:42:43 you wrote:
> 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?

In theory you just depend on the proper version of libqt4-dev, but it's tricky 
as you might indirectly reference libs that are also newer in the SDK/new PR 
so end up with a 4.6 dependency (or broken build), see below...

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

Most of the applications got compiled for Qt4.6 'by accident', in terms that 
they do not really depend on or need 4.6 (nor did the original author WANT 
that specific version), but with current SDK setup they end up being linked 
against 4.6 anyway. This is why in my previous post I said this is not 
strictly a PR1.1 problem, a similar situation might arise with other packages 
if not managed correctly.

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

AFAIK it's halted. Considering PR1.2 uses a separate repo, it makes no sense 
to promote them (yet) anyway. I would not consider prerelease 1.2 as a valid 
platform for community QA purposes.

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

Hate to be the bearer of bad news :( What we managed to agree for the PR1.2 
release is that development releases starting with PR1.2 will not be called 
libqt4-maemo5 as it's not that obvious that it's *really* just a version for 
testing, prone to breakage and not necessarily the exact one that will end up 
in the next PR. Future releases will sport the 'experimental' moniker (f.e. 
libqt4-experimental, python-qt4-experimental) so it's more clear that it (and 
stuff depending on it) are not meant to be promoted to end users. Not ideal, 
but hopefully will reduce confusion until a better solution is found that is 
acceptable for both Nokia and the community.


Regards,
Attila
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Kimmo Hämäläinen]

On Fri, 2010-05-21 at 10:00 +0200, ext Marcin Juszkiewicz wrote:
> Dnia piątek, 21 maja 2010 o 09:55:29 Nicola Mfb napisał(a):
> > On Fri, May 21, 2010 at 9:34 AM, Ville M. Vainio 
> > wrote: [...]
> > 
> > > No, it means PR1.2 will probably happen sooner than you think. If
> > 
> > A not-affirmative sentence ("will not be released for sure before X
> > weeks") may help developers to decide.
> 
> nOKIA will not tell you that. My bet is 12 November - until that I will use 
> LR1.2 on my phone (LR == Leaked Release compared to PR == Public Release).

As Eero said in one previous email, no-one in Nokia knows either :)
Because it's released when it's tested.  There are some guesses of
course, but those didn't go so well in the past as everyone knows.

-Kimmo

> 
> Regards, 

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Attila Csipa]

On Friday 21 May 2010 07:06:35 Ville M. Vainio wrote:
> On Fri, May 21, 2010 at 2:42 AM, Felipe Crochik  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.

The rationale of working out scenarios is to have a course of action if a 
similar situation arises (not necessarily with Qt or another PR). As I 
mentioned previously, I agree with Niels that this is more a packaging than a 
PR1.1/1.2 (delay) issue, PR1.2 will just make the symptoms temporarily go 
away. In other words, do not bother with PR1.1 but bother with how you 
package your packages :)


Best regards,
Attila
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Nicola Mfb]

On Fri, May 21, 2010 at 10:00 AM, Marcin Juszkiewicz
 wrote:
[...]
>> A not-affirmative sentence ("will not be released for sure before X
>> weeks") may help developers to decide.
>
> nOKIA will not tell you that. My bet is 12 November - until that I will use
> LR1.2 on my phone (LR == Leaked Release compared to PR == Public Release).

I do not need a release date, I need "a not release date"!
E.g., "our QA procedure needs 4 weeks of testing after a bug was
fixed, as the last was closed a week ago, do not expect public release
before 3 weeks, and may be delayed again".
Just to have an idea, as user I'm happy with 1.1.1, as developer I
need such information.

Regards

 Niko
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Marcin Juszkiewicz]

Dnia piątek, 21 maja 2010 o 09:55:29 Nicola Mfb napisał(a):
> On Fri, May 21, 2010 at 9:34 AM, Ville M. Vainio 
> wrote: [...]
> 
> > No, it means PR1.2 will probably happen sooner than you think. If
> 
> A not-affirmative sentence ("will not be released for sure before X
> weeks") may help developers to decide.

nOKIA will not tell you that. My bet is 12 November - until that I will use 
LR1.2 on my phone (LR == Leaked Release compared to PR == Public Release).

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


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Nicola Mfb]

On Fri, May 21, 2010 at 9:34 AM, Ville M. Vainio  wrote:
[...]
> No, it means PR1.2 will probably happen sooner than you think. If

A not-affirmative sentence ("will not be released for sure before X
weeks") may help developers to decide.

Regards

Niko
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Ville M. Vainio]

On Fri, May 21, 2010 at 10:14 AM, Marcin Juszkiewicz
 wrote:

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

No, it means PR1.2 will probably happen sooner than you think. If
someone wants to start implementing workaround schemes today it's ok,
but I'd personally suggest using the time between now and PR1.2 on
something that's actually going to see real use.

-- 
Ville M. Vainio
http://tinyurl.com/vainio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Marcin Juszkiewicz]

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  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:  h...@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Ville M. Vainio]

On Fri, May 21, 2010 at 2:42 AM, Felipe Crochik  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
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

RE: QT Packages, Repositories and PR1.2

[Felipe Crochik]

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



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

 

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Attila Csipa]

On 5/20/10, Felipe Crochik
>
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
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Felipe Crochik]

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
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-develop

Re: QT Packages, Repositories and PR1.2

[Attila Csipa]

On Thu, May 20, 2010 at 6:10 PM, Felipe Crochik  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
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Felipe Crochik]

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
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Attila Csipa]

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
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QT Packages, Repositories and PR1.2

[Daniil Ivanov]

Hi Felipe!

On Thu, May 20, 2010 at 4:26 PM, Felipe Crochik  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
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers