Comment 9 for bug 645300

(In reply to comment #4)
> (In reply to comment #2)
> > This should not be approved for Fedora. We have a mechanism for shipping
> > repository metadata, and bundling it in packages is not it.
>
> This isn't repository meta data nor is it package metadata - this is
> application data. This is nothing like comps or specspo at all. This is also
> for functionality (the client side database) that is shared between
> distributions, and other distributions don't share our repomd or the same
> packaging tools.

Richard -- how is the functionality shared by distributions? If I've followed what you've posted on your blog, then each repository has to have its own metadata (errr, "database") defining what applications are available within it. This then is told to the app-installer by registering it and saying "the database for this repo is over here". But if that's the case, why wouldn't it make sense to have the database registered by the repo itself? The main reason I can think of is that we're actually better off in allowing additional arbitrary metadata via yum than other package managers which are very hard-coded and can't do this sort of on-the-fly additional metadata :-)

> Please guys, don't just protest against this because it's not doing things the
> yum way. Putting icons and all translations in the yum repomd is not suitable
> unless you want to download large amounts of extra metadata every time a few
> packages change, and would add a large chunks of functionality to yum. I've got
> no intention of adding huge amounts of code to yum, as it already difficult to
> interface with yum using PackageKit and I really don't think yum should
> understand the concept of applications, rather than packages. yum is meant to
> be a package manager, not an application manager.

*grin* Isn't PackageKit a package manager by its very name? ;-)

Really, the line between "application" and "package" is as much a historical accident as anything. They aren't one to one mappings, sucks... but so it goes. It gives us some nice things too. I fully agree that people in general want to be installing something to actually do something (an application) vs some arbitrary package/set of packages. But that doesn't mean that we have to go to a whole new level of abstraction and metadata generation/distribution to get there.

> I've been updating hal-info quite a bit in the last few years, and this has
> worked well for this sort of data. We cannot do this repo-side and use the
> mechanism in a cross-distro way. I've talked in depth with suse, ubuntu and
> foresight developers about this, and using yum in this way is not the right
> thing to do.

As someone else mentioned, the difference is that hal-info isn't generated out of information about packages being shipped and rather is generated based on hardware. So it's more like hwdata than something like comps or specspo. Also, it seems somewhat a shame here that you've talked in depth with developers with every distribution *other* than Fedora :(