Proposed F13 feature: drop separate updates repository
jkeating at redhat.com
Wed Dec 2 17:48:59 UTC 2009
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
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.
Fedora -- Freedom² is a feature!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the fedora-devel-list