[maemo-developers] QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)
From: Anderson Lizardo anderson.lizardo at openbossa.orgDate: Thu Dec 3 15:42:32 EET 2009
- Previous message: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)
- Next message: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Dec 3, 2009 at 6:09 AM, Thomas Perl <th.perl at 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
- Previous message: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)
- Next message: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]