http://fedoraproject.org/extras/4/i386/repodata/

Chris Ricker kaboom at oobleck.net
Thu Jul 14 17:29:34 UTC 2005


On Thu, 14 Jul 2005, Matthew Miller wrote:

> On Thu, Jul 14, 2005 at 12:59:46PM -0400, Chris Ricker wrote:
> > Two big reasons for doing it external:
> > 1. it's not Yet More Crap in the spec file that will rot over time, but 
> > forever more be needed (like the current spec Group)
> 
> Well, since the current group tag is already Forever More Needed, we might
> as well reuse it for this.

If it goes in the spec at all, sure. But is Group abusable to get multiple 
tags? And if you're having to make changes to get Group usable, why not 
just kill it instead?

> > 2. it can be revised as needed, and retrofitted to existing packages, 
> > without rebuilding the world
> 
> An advantage over the tag/trove approach over the old groups scheme is that
> the hierarchy and display would be kept as external, so most sorts of
> retrofitting wouldn't require rebuild.

retrofitting's needed in the sense of something has to have a tag to be 
categorizable. So if the tag is within the rpm, all the existing rpms 
either need a rebuild (not going to happen, except perhaps for the sphere 
of Fedora) or you have to fall back to the existing meaningless Group tag

I agree that revision of tags, once in place, hopefully wouldn't be needed 
much because all the logic is external to the tag....

> Keeping the tag information in an external file has the converse problem:
> every time you want to change (or worse, add) a package, someone has got to
> edit the file. And I don't think we want to have a .metadata file for every
> package, so it's likely to be Some Central File.

But Some Central File has to change anyway every time packages change, are 
added, etc. That's a solved problem....

> > About the only reason I can think of for doing it in the spec is 
> > simplicity
> 
> Exactly. And don't underestimate simplicity. :)

Sure. I just don't see any pressing need for that info to be within the 
spec....

later,
chris




More information about the fedora-extras-list mailing list