Proposed F13 feature: drop separate updates repository

[Seth Vidal]

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
> tree).

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.

-sv