On Wed, 2009-12-02 at 14:39 +0000, Matthew Booth wrote: > The separate updates directory has been a pain for as long as I've been > using RHL/Fedora Core/Fedora. It means you have two places to look when > searching for packages manually, and twice as much to configure when > you're configuring yum. It has never benefitted me, or anybody I know, > but it has caught me out on any number of occasions. What's more, nobody > really seems to know why it's like that: it seems it's always been that > way, and nobody ever bother to fix it. If the real motivation is "I want to manually browse a single directory for all the packages" I have an alternate proposal. createrepo has the ability to take a list of packages (as paths) for input. I hypothesize that we could place all rpms for a given release in a single directory (seth will hate this as he wants to split them up based on first letter of their name for better filesystem performance), yet still maintain different repo paths for the different logical separation of rpms. One path would be the "Everything" repo, which would have repodata for the GA versions of the packages. Another path would be the "updates" repo, which has repodata for the current set of stable updates, and a third path would be the "updates-testing" repo, which has repodata for the current set of testing updates. All the repodata would reference files in a central directory (or directory tree). You could achieve a single place to manually look for packages, whilst users would still have logically separated repository metadata. Of course, I'm papering over the amount of work it would take to modify our compose tools to perform in this way, and the added work mirrors would have (they don't normally have to scan the Everything tree for changes, but now they'd have to scan a giant tree of rpms every rsync to see if anything changed), and the added complexity of trying to keep track of which packages are active in the repos and which aren't, and keeping the central directory pruned of obsolete packages. I'm certainly not signing up to work on this, but I am offering this as an alternative approach. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
