[packagekit] Common Meta-Package/Unified Names

[Richard Hughes]

On Thu, 2007-11-08 at 12:58 +0100, Sebastian Heinlein wrote:
> In the end we will need a dictonary of how to install a specific
> software on different distributions, e.g. installing the flash plugin.

As I've said before, I really don't think this is in the scope of
PackageKit (but I think other people disagree, which is fine) as it's
just an impossible problem to solve. Distros are too different. From the
very start of PackageKit, I knew that a common naming convention for
packages was doomed to failure.

> What are your current plans about this? I could think about a kind of
> provides attribute that we could add to the package.

Any solution that involves adding extra metadata to packages is not
going to work. For most of the backends trivial changes to the
underlying "doing" software (e.g. rpm) are hard to achieve, 
and this is a major new feature that is not going to be done.

> Perphaps using the
> library name or the binary could be a way: ProvidesBin=ntpdate and
> ProvidesLib=libjavaplugin.so

You're making big assumptions that fedora don't use something like
alternatives (to have two binaries installed with the same name) for
ntpdate, and that libjavaplugin.so isn't called libjavaplugin.so.6 in
another distro for compatibility reasons. The potential for failure is
just too high.

The only way I can see this working is for the thing calling into
InstallPackage (via a Resolve) to be patched into the calling
application. For instance:

epiphany wants to install flash. Upstream calls the method
InstallPackage(flash-non-free) - but fedora wants to install gnash
instead. So the fedora patch file just patches the name flash-non-free
to gnash in one place and then everything works as it should. What I
don't want is a always-out-of-date massive distro database that changes
on every distro revision. Distro patches are common, and a well
established way of making this kind of change.

That is, unless anyone's got any better ideas...

Richard.