<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thomas Goettlicher a écrit :
<blockquote cite="mid:1227181553.28543.56.camel@g168.suse.de"
type="cite">
<pre wrap="">On Thu, 2008-11-20 at 10:44 +0000, Richard Hughes wrote:
Thanks for your fast replay.
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, 2008-11-20 at 10:56 +0100, Thomas Goettlicher wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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'.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="http://www.packagekit.org/img/gpk-distro-upgrade-notify.png">http://www.packagekit.org/img/gpk-distro-upgrade-notify.png</a>
This will make any future frontends work with all distros without
patching the frontend.
</pre>
</blockquote>
<pre wrap=""><!---->Great! I didn't know this script.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">No, I don't think it is.
</pre>
</blockquote>
<pre wrap=""><!---->I agree. This popup doesn't belong into KPackagekit.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
The current Qt bindings have a function which calls GetNetworkState. I
don't know if it's used by KPackageKit though...<br>
<blockquote cite="mid:1227181553.28543.56.camel@g168.suse.de"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">6. Disable Auto Suspend while Operation
---------------------------------------
While package installation power management auto suspend should be
disabled.
</pre>
</blockquote>
<pre wrap="">Yup, the KDE frontend needs to call Inhibit() like the gnome one does.
Yell if you need a hand here.
</pre>
</blockquote>
<pre wrap=""><!---->Thanks, sounds good.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->Our package management's solver supports that, but it is a black box for
me. Details about that topic are in Duncan's blog:
<a class="moz-txt-link-freetext" href="http://duncan.mac-vicar.com/blog/archives/347">http://duncan.mac-vicar.com/blog/archives/347</a>
Thank you very much for your comments.
Thomas
</pre>
</blockquote>
<br>
</body>
</html>