Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
2009/12/2 Anderson Lizardo anderson.liza...@openbossa.org: 2009/12/2 Benoît HERVIER kher...@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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
On Thu, Dec 3, 2009 at 6:09 AM, Thomas Perl th.p...@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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
On Thu, Dec 3, 2009 at 3:42 PM, Anderson Lizardo anderson.liza...@openbossa.org 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@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
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 mvartiai...@gmail.com On Tue, Dec 1, 2009 at 5:39 PM, Anderson Lizardo anderson.liza...@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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Benoît HERVIER - http://khertan.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
2009/12/2 Benoît HERVIER kher...@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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
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@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
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 mvartiai...@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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
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/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)
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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 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 11:32 AM, Mikko Vartiainen mvartiai...@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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 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 5:39 PM, Anderson Lizardo anderson.liza...@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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
