|
Ok, I've put up a version that I think is ready for testing on github: http://github.com/ermo/upgradefl/
It's a bit of a hack, but it enables/disables buttons in the interface based on the conary exit status. I consider the current version of upgradefl 'beta-ready'.
Please download and test from the above URL. I have tested the upgradefl.py script both by running it as 'sudo python upgradefl.py', 'sudo ./upgradefl.py' and 'gksu upgradefl.py' and it runs fine for me.
The script has 3 steps. Step 1 takes care of updating conary and will only allow progress to the other steps if updating conary is successful. Step 2a attempts to do a 'conary updateall'. If the 'conary updateall' has not completed successfully after 3 tries, Step 2b will become available, which allows the user to 'conary migrate' his system. If at any of the steps 2a or 2b, the conary command completes successfully, a modal dialog box will pop up informing the user that the upgrade/migrate finished and that pressing the 'exit' button will close the application. usability issues:
how will the script be executed? the script does not complain if it is not run as root. do we need to consider the possibility that upgrading conary by itself fails? should we fall back to conary updateall with the old version instead of failing? Michael,
Is this productized enough for your tastes? During my tests, I've always assumed that the script would be run as root by conary or would prompt for a password (for instance via gksu). Is that assumption wrong? The rationale for updating conary before trying to update anything else was that newer conary versions are expected to be either faster, more correct or both. |
||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Open
Blocker
Create a PackageKit replacement that will take care of updating FL systems until such a time that the PackageKit Conary back-end is functional again.
It can be tested stand-alone.
When it works, it will be embedded into a conary group script as a heredoc.
This embedding can be tested by building a group in a testing repository if we want. However, we could just test on QA and make sure that the script adjusts to the label context and let folks put PK back on their QA systems as part of getting PK ready to go again. That would get rid of the need to build groups on test repositories and might be faster.
But the first thing is clearly to actually make the program, and test that it does what was specified...