RPM

Comment 8 for bug 645300

Revision history for this message
In , Bill (bill-redhat-bugs) wrote :

Feh. Someone asked me for my opinion. Well, you're all right, and you're all wrong. :P

I agree with Richard - there's value in having this be a distribution neutral standard, and you're not going to get there by just creating another metadata file in createrepo. Moreover, referring to 'comps' and 'specspo' in the past is a little odd - comps-extras still exists, as does the specspo package. Furthermore, given how the data is defined, there's no good way to have it in the package metadata and have it update with sane, low bandwidth, semantics.

However, I also agree with Jesse - having this in package format this way isn't good either. Building this out of band against the repository is a big old hack, and doesn't scale or translate well. You want to automate these sorts of tasks so they're always up to date. Moreover, having a new package each time doesn't gain you any sorts of caching benefits.

What you really want is an incremental protocol that can deliver the new icons & entries w/translations since the last time you updated. Neither a package, nor the yum metadata, fits this well. Honestly, an online service with local caching seems more appropriate.

(As a side point, legally, you'd have to have the license be "A & B & C & D.."... where that's the license of all the icons in total. And don't forget trademarks. This gets messy fast.)