[packagekit] Package update policy

Richard Hughes hughsient at gmail.com
Wed Sep 26 12:47:14 PDT 2007


On Wed, 2007-09-26 at 15:21 -0400, Bryan Clark wrote:

> I had made some notes on package update policy a while back and now
> have been reprimanded for not promptly sharing :)

Good! :-)

> So here they are:
> 
> Defaults
>   - Daily updates on idle usage if possible ( somewhat complicated
> if() statement )

Yes, Idle detection is on the radar. This is important, and it's
session, so we can just ask gnome-screensaver.

>   - Silently download updates in the background

Hmm difficult, as UpdateSystem is a one-method call, not a two level
"download" and then "install". We could fix that tho, although I'm not
sure the backends would be able to do what we wanted.

>   - Does not ask to perform updates ( alerts of this default at first
> update )
> 
> Daily updates are probably an ideal default, but it should try to be
> done when system is idle, i.e. the user is away from the computer.
> I'm not sure if checking for updates is a resource intensive project,

Checking no, doing yes.

>  I suppose that's a back-end independent issue really but for the most
> part updating is somewhat resource intensive and should be done when
> the computer isn't being actively used.  That said there are lots of
> gotchas with this in terms of security updates or systems that are
> used and then suspended or shutdown without much idle time; each of
> which I believe can have a simple solution. 

I figure try doing when idle, and if never idle, just doing the action
anyway...

> Downloading the updates (and dependencies) in the background allows
> for a UI that is a simple question of "Do you want these installed?"
> with no secondary response of "Now wait while I get those things you
> asked for".  For people who are paying for bandwidth by the byte or
> something this is a tricky situation, we could try to be smart and
> detect if you're on a connection like this, however those smarts are
> bound to fail often and be somewhat confusing.

Sure. People with free EDGE want to do updates over dial up, but users
on GPRS probably don't.

>   Instead if the Package Update simply always shows it's icon in the
> system tray when it's downloading, it should be good enough combined
> with a preference for never automatically downloading updates. 

Yup.

> Automatic updates are a smart idea, however some people like to have
> control over their computer being smart.  So there is a first time
> usage scenario that covers the automatic nature of the system update
> allow for a point at which people can configure the application or let
> it do what it does automatically. 

I figured choose sane defaults, to not bombard the user with questions
on first install...

> First Time Use Scenario
>   - Wait until ideal time to update 
>   - If updates are available show Package Update icon and begin
> download [ tooltip: Downloading New Updates Available]
>   - Wait until Person has returned to computer ( not idle ) 
>   - Advertise that the Package Updater has downloaded updates via a
> notification icon
>     "Updates are ready to be installed but will wait until your system
> is idle again.  All future updates will be performed automatically" 
>     [[Install Updates Now]] [Install Updates Later] [Configure...]
> 
> 
> The whole reason behind this scenario is so a minority of people can
> prevent the updater from being automatic when they want it to be
> manual without asking too many question up front which we assume would
> confuse or annoy the majority of users who don't understand or don't
> care.  

Sure. I think we do need to ask the user at least once from a privacy
point of view.

> Normal Run Scenario ( started once daily while the system is idle )
>   - Show systray icon while checking for available updates
>   - Keep systray icon around if there are update and begin downloading
> them
>   - Begin update once all packages and their dependencies are
> downloaded 

Sure, see above.

> I wanted to do the first step completely under the radar, especially
> if it's happening while the person is using the computer.  Having a
> little icon appear in your systray everyday and then disappear rather
> quickly (because there were no updates) could be a little
> disconcerting to your average user.  But if we're able to do it on
> idle for the most part then it just won't matter. 

Idle is the plan.

> I saw you have a couple different icons for the different states that
> occur, it's probably good to keep the first one innocuous looking and
> then a "downlading" style icon, followed by an "updating" style
> icon... defining those iconic meanings is going to be like a trip in
> the park :) 

Yup. I'm using mail-send-receive at the moment for downloading. Not
cool.

> Interrupted During Update Scenario (person comes back to the idle
> system while it's being updated)
>   - Systray icon shows updater in progress
>   - Display notification bubble
>     "Update in Progress\n 
>      10 of 100 packages updated"
>     [Watch Update Progress] [Configure...]
> 
> I don't think we need a close bubble or ignore action here because
> there should be a close icon, also I don't really know that you have a
> UI for watching the updates happen but I'm assuming you do :) 

Yup, you can get to it in the dropdown from the icon. I can tell you've
not tried out the code yet :-)

> As for the System Update Preferences UI I'd go with something like
> this.
> 
> -----------------------------------------------------------------------
> System Update Preferences
> 
>   [x] Automatically Check for Updates When Idle 
> 
>     [Every Day \/] Check for new updates
> 
>     [x] Download updates automatically
> 
>     (o) Never ask for confirmation, perform all updates automatically
>     ( ) Always perform security updates, but ask otherwise 
>     ( ) Always ask before updating anything

Hmm. not very new user friendly. I need to test this on my girlfriend -
if she can get it, then we've won.

> Hope I'm not coming into the game too late.

Nope, there's nothing in git yet; I appreciate the help.

Thanks,

Richard.





More information about the PackageKit mailing list