[packagekit] Features discussion/request KPackageKit

Thu Nov 20 04:15:46 PST 2008

Thomas Goettlicher a écrit :
> 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.
>   
The current Qt bindings have a function which calls GetNetworkState. I 
don't know if it's used by KPackageKit though...
>   
>>> 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
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/packagekit/attachments/20081120/b1d22a58/attachment-0001.html