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@gmail.com> 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

Anderson Lizardo wrote:

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

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

However, there might still be a question about how to convince an
end user to upgrade a package that he has not actually installed. In
"Maemo 5" case that is easy, but in other cases it might require some
additional communication.

One solution could be that the Application Manager showed other
user/* packages that depends on meta user/* packages. That way an user
might understand that if he upgraded Python package (or Microfeed
package), gPodder (Mauku), for example, would benefit from that. Maybe
those meta packages should be in a separate section (user/backend,
user/platform, user/libraries, or similar).

BR,

Henrik

--
Henrik Hedberg - http://www.henrikhedberg.net/

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

--
Mikko Vartiainen

On Tue, Dec 1, 2009 at 11:32 AM, Mikko Vartiainen <mvartiainen@gmail.com> 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

On Tue, Dec 1, 2009 at 5:39 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> 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

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@gmail.com>

> On Tue, Dec 1, 2009 at 5:39 PM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> 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
>



--
Benoît HERVIER - http://khertan.net/

2009/12/2 Benoît HERVIER <khertan@khertan.net>:
> 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

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

2009/12/2 Anderson Lizardo <anderson.lizardo@openbossa.org>:
> 2009/12/2 Benoît HERVIER <khertan@khertan.net>:
>> 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

On Thu, Dec 3, 2009 at 6:09 AM, Thomas Perl <th.perl@gmail.com> 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