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