On Thu, 2007-08-23 at 02:23 +0100, Richard Hughes wrote:
On 23/08/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
> On 8/22/07, Owen Taylor <otaylor(a)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