Proposed F13 feature: drop separate updates repository
skvidal at fedoraproject.org
Wed Dec 2 18:09:25 UTC 2009
On Wed, 2 Dec 2009, Jesse Keating wrote:
> 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),
And better webbrowser and webserver performance since having A GIANT list
eats my webbrowser often.
> 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
the paths don't matter - you just need to generate the lists and feed that
into SOME sort of 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.
The compose tools would just have to make a list of pkgs in what dirs -
a list they already have.
I guess what I don't see is what the net benefit is here.
the merger of repos is already happening at the yum layer.
More information about the fedora-devel-list