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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
