Mailing List Archive: Maemo: Developers

QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)

Index | Next | Previous | View Threaded

anderson.lizardo at openbossa

Dec 1, 2009, 6:28 AM

Post #1 of 9 (801 views)
Permalink

*QA Process for non user/ packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)**

On Tue, Dec 1, 2009 at 9:51 AM, Mikko Vartiainen <mvartiainen [at] gmail> wrote:
> You can promote PyMaemo packages to extras-testing but it's not the
> solution, because it doesn't help getting them to Extras (you can't
> promote them there). Even if newer versions of non user/ packages were
> promoted to Extras it doesn't help much getting them to end users
> devices if they had earlier version of them installed because of how
> Application Manager works. Currently getting something to updated
> requires that update is somehow visible through user/ package both in
> Application Manager and packages interface autopromotion algorithm.

Sorry but it is still not clear to me how to get fixes to non user/*
packages to the users' devices. If I understand correctly, Application
Manager does not follow the same behavior as apt-get on this case,
i.e. it will not upgrade non user/* packages on Device even if there
are new versions in extras, is that right?

> Promotion system could probably be changed that it always promotes
> newer version of non user/ package. One option would be that package
> maintainer can promote updates of non user/ package to extras
> manually, but that circumvents the whole qa process.

If I remember correctly, the QA process is currently very user/*
centered. I followed the discussions on last meeting too, and the
process does not seem to cover the updates for non user/* packages. So
right now we have a serious problem (IMHO) where we can get non user/*
package updates delivered to final users through a clean process.

Some user suggested once creating meta user/* packages for libraries,
python modules etc. that need updates, but I think this just too
hackish, and even if we proceed and do this, how do we convince the
end user to install it?

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

anderson.lizardo at openbossa

Dec 1, 2009, 7:39 AM

Post #2 of 9 (763 views)
Permalink

*Re: QA Process for non user/ packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)** [In reply to]

On Tue, Dec 1, 2009 at 11:32 AM, Mikko Vartiainen <mvartiainen [at] gmail> wrote:
>>
>> I still suggest meta user/* packages. Nokia is actually using meta
>> user/* packages (for example, "Maemo 5" package is a meta package
>> pulling the platform non user/* packages when upgraded).
>
> Meta packages are unfortunately the only working way
> get library updates to users. I still would hate to
> see all libraries in Application Manager, even if
> they were semi hidden to some category. Only _good_
> solution that I can see is that Application Manager
> would work the same way as apt-get and upgrade all
> packages (except the Nokia meta package).

The problem being that the meta-package will pull *all* PyMaemo
packages and not just what the user wants/needs :/

Unless Application Manager honours Suggests: fields ? in this case we
could put all non-core Python packages under that field.

The other solution is to fix Application Manager :o)

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

mvartiainen at gmail

Dec 1, 2009, 7:55 AM

Post #3 of 9 (763 views)
Permalink

*Re: QA Process for non user/ packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)** [In reply to]

On Tue, Dec 1, 2009 at 5:39 PM, Anderson Lizardo
<anderson.lizardo [at] openbossa> wrote:
> The problem being that the meta-package will pull *all* PyMaemo
> packages and not just what the user wants/needs :/

Yes, meta packages would bring more problems than solve them.

> Unless Application Manager honours Suggests: fields ? in this case we
> could put all non-core Python packages under that field.

I don't think HAM knows about suggests field.

> The other solution is to fix Application Manager :o)

IMO Application Manager is broken from community (Extras) perspective.
From Nokia's perspective it's probably not broken because they can
control that single meta package for SSU. How could we get that fixed?

---
Mikko Vartiainen
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

khertan at khertan

Dec 2, 2009, 6:13 AM

Post #4 of 9 (751 views)
Permalink

*Re: QA Process for non user/ packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)** [In reply to]

What happen if i push something for testing like PyGTKEditor for example ...
but once this one has been push, a new version of a python binding used by
PyGTKEditor exist in the extras-devel, we cannot push it to extras-testing
manually ? But as there isn't any new version of PyGTKEditor, i ll recreate
one package in extras-devel with a greater number just to push the python
binding.

What happen now if this binding is a important update ?

2009/12/1 Mikko Vartiainen <mvartiainen [at] gmail>

> On Tue, Dec 1, 2009 at 5:39 PM, Anderson Lizardo
> <anderson.lizardo [at] openbossa> wrote:
> > The problem being that the meta-package will pull *all* PyMaemo
> > packages and not just what the user wants/needs :/
>
> Yes, meta packages would bring more problems than solve them.
>
> > Unless Application Manager honours Suggests: fields ? in this case we
> > could put all non-core Python packages under that field.
>
> I don't think HAM knows about suggests field.
>
> > The other solution is to fix Application Manager :o)
>
> IMO Application Manager is broken from community (Extras) perspective.
> From Nokia's perspective it's probably not broken because they can
> control that single meta package for SSU. How could we get that fixed?
>
> ---
> Mikko Vartiainen
> _______________________________________________
> maemo-developers mailing list
> maemo-developers [at] maemo
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>

--
BenoÃ®t HERVIER - http://khertan.net/

anderson.lizardo at openbossa

Dec 2, 2009, 6:53 AM

Post #5 of 9 (745 views)
Permalink

*Re: QA Process for non user/ packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)** [In reply to]

2009/12/2 Benoît HERVIER <khertan [at] khertan>:
> What happen if i push something for testing like PyGTKEditor for example ...
> but once this one has been push, a new version of a python binding used by
> PyGTKEditor exist in the extras-devel, we cannot push it to extras-testing
> manually ? But as there isn't any new version of PyGTKEditor, i ll recreate
> one package in extras-devel with a greater number just to push the python
> binding.
>
> What happen now if this binding is a important update ?

That's what is happening at the moment with python-osso.

The version in extras & extras-testing (0.4.0-0maemo1) has a bug where
the "__init__.py" file is not generated (because it lacked the
python-central dependency). The issue has been fixed in 0.4.0-0maemo2
some time ago, but it does not go to extras-testing because there is
no package depending _explicitely_ on that new version.

So unless someone promotes a user/* package to extras-testing that has
"Depends: python-osso (>= 0.4.0-0maemo2)" , python-osso will remain
broken on extras & extras-testing.

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

rael at edge

Dec 2, 2009, 7:08 AM

Post #6 of 9 (743 views)
Permalink

*Re: QA Process for non user/ packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)** [In reply to]

Hello!

> That's what is happening at the moment with python-osso.

[...]
> So unless someone promotes a user/* package to extras-testing that has
> "Depends: python-osso (>= 0.4.0-0maemo2)" , python-osso will remain
> broken on extras & extras-testing.

That also happend for me recently with libIllumination even in
extras-devel! A bugfix does not get installed by the device.

Is this the same effect? If yes, thrilling is that I have a n:1
constellation where multiple application depend on the same library, where
the applications do not have any dependencies on each other. So I must
increase the version and force a rebuild with a higher dependency for *all*
application packages? If I miss one, funny things will likely happend, with
some people having the new version and some the old. The effect occured
recently. I assume because before libIllumination had a user/* category
(which was identified as bug).

That all sound very broken... Imaging this happening for the community
based hildon add-on controls library, which is likely widly spread in
future.

--
GruÃŸ...
Tim
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

th.perl at gmail

Dec 3, 2009, 2:09 AM

Post #7 of 9 (738 views)
Permalink

*Re: QA Process for non user/ packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)** [In reply to]

2009/12/2 Anderson Lizardo <anderson.lizardo [at] openbossa>:
> 2009/12/2 Benoît HERVIER <khertan [at] khertan>:
>> What happen if i push something for testing like PyGTKEditor for example ...
>> but once this one has been push, a new version of a python binding used by
>> PyGTKEditor exist in the extras-devel, we cannot push it to extras-testing
>> manually ? But as there isn't any new version of PyGTKEditor, i ll recreate
>> one package in extras-devel with a greater number just to push the python
>> binding.
>>
>> What happen now if this binding is a important update ?
>
> That's what is happening at the moment with python-osso.
>
> The version in extras & extras-testing (0.4.0-0maemo1) has a bug where
> the "__init__.py" file is not generated (because it lacked the
> python-central dependency). The issue has been fixed in 0.4.0-0maemo2
> some time ago, but it does not go to extras-testing because there is
> no package depending _explicitely_ on that new version.
>
> So unless someone promotes a user/* package to extras-testing that has
> "Depends: python-osso (>= 0.4.0-0maemo2)" , python-osso will remain
> broken on extras & extras-testing.

Maybe a meta-package that depends on all new PyMaemo packages
would do the trick? AFAIK there is a "user/hidden" section that lets the
package appear in "upgrade" and "uninstall" views, but not in the normal
"install" view. So users won't see it in the normal application list, but
would have the option to remove or upgrade the package:

http://maemo.gitorious.org/hildon-application-manager/mainline/commit/f7b4542b3c77114a95e2803708cec8eeff3409f7

(I don't know if this commit has made it into a release version yet, though)

Thomas
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

anderson.lizardo at openbossa

Dec 3, 2009, 5:42 AM

Post #8 of 9 (730 views)
Permalink

*Re: QA Process for non user/ packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)** [In reply to]

On Thu, Dec 3, 2009 at 6:09 AM, Thomas Perl <th.perl [at] gmail> wrote:
> Maybe a meta-package that depends on all new PyMaemo packages
> would do the trick? AFAIK there is a "user/hidden" section that lets the
> package appear in "upgrade" and "uninstall" views, but not in the normal
> "install" view. So users won't see it in the normal application list, but
> would have the option to remove or upgrade the package:
>
> http://maemo.gitorious.org/hildon-application-manager/mainline/commit/f7b4542b3c77114a95e2803708cec8eeff3409f7

As I said on a previous message this solves the "promote packages to
extras" issue, but still doesn't solve:

* how to convince the user of installing this meta pacakge (does he
ever have to know about Python to install e.g. gPodder?)

* installing this metapackage will obviously install *all* PyMaemo
packages, which will take unnecessarily precious storage even if not
all packages are used.

* If I understood Mikko's explanation right, HAM will not upgrade a
dependency automatically (unlike "apt-get upgrade"), unless a
installed (or to be installed) user/* application exclicitely Depends
on that new version (i.e. uses "Depends: package (>= x.y)", where x.y
is the newer version). If that's correct, each new version of a
dependency that contains a important fix will require *all* Python
applications updating their versions to include the new required
version in debian/control, if we want the user to have that fix.

Mikko: feel free to correct me if I made a mistake.

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

mvartiainen at gmail

Dec 3, 2009, 6:20 AM

Post #9 of 9 (722 views)
Permalink

*Re: QA Process for non user/ packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)** [In reply to]

On Thu, Dec 3, 2009 at 3:42 PM, Anderson Lizardo
<anderson.lizardo [at] openbossa> wrote:
>
> * If I understood Mikko's explanation right, HAM will not upgrade a
> dependency automatically (unlike "apt-get upgrade"), unless a
> installed (or to be installed) user/* application exclicitely Depends
> on that new version (i.e. uses "Depends: package (>= x.y)", where x.y
> is the newer version). If that's correct, each new version of a
> dependency that contains a important fix will require *all* Python
> applications updating their versions to include the new required
> version in debian/control, if we want the user to have that fix.
>
> Mikko: feel free to correct me if I made a mistake.

Yes, you understood correctly.

> * installing this metapackage will obviously install *all* PyMaemo
> packages, which will take unnecessarily precious storage even if not
> all packages are used.

But this user/hidden (which I've never heard of) is different. It
seems that user/hidden packages get the same treatment as other user/
packages for updates, but they cannot be separately installed.
User/hidden pacakge could be part of the solution, but it's still
awkward and unnecessary hack compared to normal upgrades.

If user/hidden was used all python apps should depend on big pymaemo
metapackage, which would pull all packages even if not needed as you
said. But if user/hidden is already (or soon) there, it might be the
best option available. After all application space isn't big issue
anymore, and after installing 2-3 python application you have
practically installed all pymaemo packages anyway.

--
Mikko Vartiainen
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads