On Thu, 2007-08-23 at 02:23 +0100, Richard Hughes wrote:
> On 23/08/07, Jeff Spaleta <jspaleta@xxxxxxxxx> wrote:
> > On 8/22/07, Owen Taylor <otaylor@xxxxxxxxxx> 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
--
Fedora-desktop-list mailing list
Fedora-desktop-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
