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