[packagekit] Features discussion/request KPackageKit

[Thomas Goettlicher]

On Thu, 2008-11-20 at 10:44 +0000, Richard Hughes wrote:
Thanks for your fast replay.

> On Thu, 2008-11-20 at 10:56 +0100, Thomas Goettlicher wrote:
> > 1. Warn and Add when No Update Repository is Defined
> > ----------------------------------------------------
> > kupdateapplet shows a warning when no update repository exists and gives
> > the user a chance to add an update repository. kupdateapplet assumes
> > that no update repo exists if no repository's name or url contains the
> > string 'update'. Perhaps there is a cleaner way. 
> > Dunno a distro independend way to find and add an update repo. On
> > openSUSE it is done by 'yast2 online_update_configuration'.
> 
> Right, this sort of heuristic belongs in the suse-specific backend. What
> I would say is best is:
> 
> (no update repos configured)
> 
> C: GetUpdates()
> S: ::Warning(NO_UPDATE_REPOS_CONFIGURED, "no update repos are
> configured")
> S: ::Finished(SUCCESS)
> 
> and then you get a little notification box with the warning. This would
> then work in KDE and GNOME, and be localised.
Yes, that sounds like a clean way.
Besides the warning it might be useful to show a button that adds an
appropriate update repo. A script 'pk-add-update-repo.sh' (similar to
'pk-upgrade-distro.sh') could do this task.


> > 2. Manual Installation on Errors
> > --------------------------------
> > When an operation like package update fails (e.g. dependency problems)
> > kupdateapplet allows to start openSUSE's packagemanager that supports
> > those complicated scenarios. 
> 
> Hmm, surely the issue is you need to fix the repo? What if there's no
> user in front of the computer and it's an automatic update? Can't you do
> the equivalent of a "yum --skip-broken update" where you update
> everything that's possible, and then return INFO_BLOCKED for the others?
There are scenarios where dependency conflicts prevent the installation
of a package. In this case the user has to decide whether he wants to
downgrade 'foo' or remove 'bar' to make it possible to update 'foobar'.
Sometimes it's even worse. I think it is a too complicated task for
PackageKit to provide such a complex workflow. 
That's the reason why I think it would be great to have the possibility
to call the distro specific packagemanager if the operation is too
complex.


> > 3. Distribution Upgrade
> > -----------------------
> > kupdateapplet asks via 'GetDistroUpgrades' for an available distribution
> > upgrade and starts '/usr/bin/wagon' if needed and the user wishes to.
> > We'd need a distribution independent way to trigger a distro upgrade.
> 
> Right. You need to add wagon
> to /usr/share/PackageKit/pk-upgrade-distro.sh and then get the
> GetDistroUpgrades calling method to call execute pk-upgrade-distro.sh
> 
> In the gnome applet I've tied the more information button to the script
> -- for fedora this launches preupgrade:
> http://www.packagekit.org/img/gpk-distro-upgrade-notify.png
> 
> This will make any future frontends work with all distros without
> patching the frontend.
Great! I didn't know this script.



> > 4. Send System Profile
> > ----------------------
> > kupdateapplet shows a popup that asks the user whether he wants to take
> > part with his system data in the smolt project. This isn't package
> > management specific and I don't know whether KPackageKit is the right
> > application for that.
> 
> No, I don't think it is.
I agree. This popup doesn't belong into KPackagekit.



> > 5. Postpone Operation when System isn't Ready
> > ---------------------------------------------
> > When the system is busy, on battery or not connected to the network
> > checking for updates or installation of updates should wait until the
> > system is ready.
> 
> Right, this is what I do with the gnome frontend, so the KDE one should
> do this for sure. You can use the GetNetworkState() API call on
> org.freedesktop.PackageKit to be able to work with and without
> NetworkManager.
Excellent. 

/usr/bin/on_ac_power from the package pm-utils tells whether the system
is on battery and getloadavg from stdlib.h tells the systemload.

> 
> > 6. Disable Auto Suspend while Operation 
> > ---------------------------------------
> > While package installation power management auto suspend should be
> > disabled.
> 
> Yup, the KDE frontend needs to call Inhibit() like the gnome one does.
> Yell if you need a hand here.
Thanks, sounds good.


> > 7. Install Firmware and Drivers
> > -------------------------------
> > a) Search and install firmware that belongs to files
> > in /var/run/PackageKit/udev/*.
> > b) KDE Solid::DeviceNotifier sends a signal when new hardware is
> > attached. WhatProvides(drivers) returns needed drivers.
> 
> Yes, what we have at the moment in GpkHardware is a skeleton on what it
> should be. If you have any good ideas on how to match up "hardware" with
> "drivers" it would be good.
Our package management's solver supports that, but it is a black box for
me. Details about that topic are in Duncan's blog:
http://duncan.mac-vicar.com/blog/archives/347


Thank you very much for your comments.
Thomas


-- 
Thomas Goettlicher
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)