Last week I sat down and implemented some of the gnome-control-center mockups for GNOME 3.
This is the screen mockup, which as the name suggests, is all the settings related to the screen.
We’ve also made the power panel much, much easier to use. All the power-user settings are still available in GSettings, if you’re the geeky sort who likes to tweak. The conclusion we’ve come to, is that we should fix drivers, rather than provide workarounds for hardware bugs in the UI.
This is all available right now if you compile using jhbuild, and will be available in Fedora rawhide soon.
Yesterday I merged a patch to PackageKit which added the UpgradeSystem() method to the transaction interface. This is the natural compliment of the GetDistropUgrades() method which was added last year. This allows a session user to upgrade the OS using the same familiar PackageKit tools, and without doing dumb things like asking for the admin pasword and running GTK and python graphically as the root user.
In Fedora, we use a package called preupgrade. This was created by Will Woods and Seth Vidal in 2008, and I was asked to maintain it last year. I’ve been helped by James Laska, which has been very much appreciated. Preupgrade has been fixed up a few times, but the majority of the code is the same as when I inherited it. Preupgrade was a nearly-good-enough monolithic lump of code that kinda worked.
In my humble opinion, Fedora (and all other distros) are too small to maintain such mission critical stuff such as distribution upgraders. The PackageKit project has shown people that by distributions combining forces, they can share frontends and write different small backends and free up developers for other things. As a team, we have a better quality product than the results of one developer on one distribution.
So I figured preupgrade should have the same love. 99% of the preupgrade code is GUI interface code and this was easily converted to C, and to use PackageKit. The result of this is in gnome-packagekit git master, with a new tool gpk-distro-upgrade.
Don’t go and try this code just yet. None of the preupgrade backend code has been moved to the yum backend, although I don’t assume I’ll have many problems, and plan to do this later in the week. If you want to test this use the “dummy” backend, although this won’t actually perform any changes of course.
Hopefully some of the other distros can play with gpk-distro-upgrade and improve it. Hopefully the translators will file bugs about the bad English, and translate it to 50 languages. Hopefully another distro will port their os updater to use this new functionality and find bugs or speed up the common code a little.
All I know is preupgrade will live on as part of PackageKit, and now it’s targeted at a bigger audience than just the few million of Fedora users.
PackageKit tries really hard to work for these people. PackageKit is designed for these people.
Debconf is a simple protocol that dpkg uses to ask the user configuration data at install time. I think it’s generally a bad idea, as installing should generally be silent and automatic and configuration should be a separate step. That said, PackageKit needs to also work on Debian, as some people seem to really like debconf and are not happy shipping a PackageKit that won’t talk the debconf protocol.
So, last weekend I sat down and wrote the required PackageKit-glib2 patches to make the PackageKit-enabled frontends setup a pipe for use in apt, and to spawn debconf when required. Of course, this is a no-op for things like searching and when a package needs no configuration, but for other packages it blocks (urgh) the transaction and the user gets asked questions. Of course, if the transaction is running non-interactively, then the backend won’t ask any questions at all.
Of course, I’m kinda disappointed someone from Debian didn’t write the patch themselves; with all the blogs, wiki articles and emails about the “lack of debconf support in PackageKit” it would have been less typing to actually write the patch. Hey ho, it’s done now. If you install the recently released 0.6.10, then it “just works” with no re-compiles of any front-end clients required.
Of course, I should also like to thank Daniel Nicoletti and Sebastian Heinlein for development help, and Matthias Klumpp for testing. Thanks.