[Bug 488968] Review Request: fedora-app-install - Fedora application data

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=488968





--- Comment #8 from Jeremy Katz <katzj at redhat.com>  2009-03-06 16:38:31 EDT ---
(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 :(

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.