[packagekit] GNOME summit and more about GPG keys

[Robin Norwood]

Richard Hughes <hughsient at gmail.com> writes:

> On Tue, 2007-10-09 at 21:11 -0400, Robin Norwood wrote:
>> ...There was a
>> bit of a discussion about "How applications can install plugins with
>> PackageKit".  For instance, gimp plugins and gstreamer codecs.  To be
>> able to do this, we should probably have simple python and C bindings to
>> install things with a semantic of "give me a package which provides
>> 'x'".  The bindings we have now are pretty close, and maybe just example
>> code needs to be easily available.
>> 
>> However, one problem is that there isn't a consistant cross-distro way
>> that I know of to name these sorts of deps...so either distros will need
>> to become consistant or the deps need to be generated and maintained
>> somewhere.
>> 
>> Thoughts on this?
>
> Okay, this is a hard problem to solve. I don't think we can think for
> one second that we can get all the distros to agree on common names for
> packages, it's just not going to be possible politically.
>
> I think there are three potential ways of working around this:
>
> 1. Each backend allows a what_provides(divx-codec) type parameter, which
> is basically shifting the work onto the backends - something that isn't
> going to be popular or possible with most of the backends. Also,
> multiple packages could provide functionality, for instance
> gstreamer-plugins-bad, vlc or mplayer.
>
> 2. We provide a big long compatability list on name->distro_name, so we
> have firefox->firefox-bin on ubuntu and firefox->mozilla-firefox on
> conary (made up examples) - this would be a long list, which has to be
> updated for each distro version and for each installable package. Not
> cool.
>
> 3. We do the brute force solution and shift this on to the packagers.
> Upstream would hardcode firefox-bin, and in the fedora spec file we
> would add a patch to change this to the distro name, e.g.
> mozilla-firefox. This would mean that we only have to patch one software
> package in each distro, and don't have to mainain giant lists or require
> each backend to track the files installed. We also get the GNOME tools
> to install the gnome plugins, and similar with KDE.
>
> Solution 3 seems to have least drawbacks in my eyes. Totem could be
> patched to install gstreamer-codec-bad on fedora and install
> restricted-codecs on ubuntu - totem already knows what codec it needs.
> This should mean that as package names change, the distro people are
> able to make immediate changes without ensuring some sort of
> compatibilty with certain versions of a compatibility list.

Well, don't various packaging systems have a method to say that 'this
package provides "foo"'?  Wouldn't it be better to include that
information in the package providing "foo", using some common naming
scheme, than making apps track distro changes?

IE, using some agreed upon scheme like the one David proposes above, the
burden falls upon the packager (maybe with hints from the upstream
application as to what capabilities it might request).

-RN

> To actually do this, the code is already in place. Look in
> gnome-packagekit/src/* at the pk-install-package binary. Basically this
> resolves the name "firefox" to "firefox-bin;2.01;x64;fedora" and
> installs the result with a progress UI. Applications could use that
> helper executable, or just use the libpackagekit API directly, it's only
> a few tens of lines of code.
>
> Richard.
>
>
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching