PackageKit Misconceptions

David Zeuthen davidz at redhat.com
Thu Aug 23 16:56:56 UTC 2007


On Thu, 2007-08-23 at 02:23 +0100, Richard Hughes wrote:
> On 23/08/07, Jeff Spaleta <jspaleta at gmail.com> wrote:
> > On 8/22/07, Owen Taylor <otaylor at redhat.com> wrote:
> > > I'm sure we can work with legal to come up with something acceptable.
> >
> > I hope so. I just want to make sure you guys don't go crazy on
> > implementation mock-ups just to get your bubbles bursted by the
> > non-technical constraints.
> 
> Ohh, it's entirely doable in the current PackageKit design, it's just
> an argument on whether it's a good idea to do so or not.
> 
> What I'm currently thinking is:
> 
> User installs livna/internal/freshrpms repo rpm
> User types in mplayer into application finder
> User clicks install
> 
> PackageKit gets the GPG key message, and returns an error enum
> gpg-key-required and the description of the repo as the technical
> data. The install "fails" and a dialog is presented to the user.
> 
> Then, as a seporate task the user can click on the button in the
> failure GUI and the GPG key can be imported (using PolicyKit as
> auth?). Then the install can be retried and should succeed.
> 
> Sounds insane to me, but allows us to keep (and further improve) the
> GPG repo signed issue if we want to, or have to, keep it.

Sounds sane to me actually. Initially I'd just show the GPG key and name
and link to a bunch of disclaimers/explanations; it will be pretty
useless initially but on par with what yum / pirut does [1]. 

I like the idea that GPG importing is a separate application (but should
still live in the PackageKit tarball/repository IMO); it makes it easier
for contributors to hack on it to land some of the ideas about trust
metrics etc.

Regarding abstraction, does the other packaging formats and/or
depsolvers work in a similar way? Something to think about.

     David

[1] : http://www.pro-linux.de/berichte/jpgs/fc5-test2/fc5-pirut.png





More information about the desktop mailing list