On 02/12/09 17:40, Jesse Keating wrote:
On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote:
* It shifts "costs" from "users" to "vendor"
and from "mirrors" to "master".
* It helps users who are using networked installs to spare bandwidth
(avoids downloading obsolete packages from "Everything"/"Fedora").
Admitted, for most users, it would change almost nothing.
People doing network installs can either add the updates repo to their
kickstart, or check the box in the anaconda UI, so that the updates
repos are considered at install time. No download of duplicate data.
In fact, having separate repos would likely cost less bandwidth. If we
only had one combined repo, there would be many duplicate packages,
especially if we went the route of having updates-testing mixed in and
only marked by some update tag. We'd have to keep sets of what's in
updates-testing, updates, and the GA release set, and all of that would
be in one repodata set. Everybody doing a network install, whether they
wanted updates, updates-testing, or not would have to download and
consume that larger repodata, introducing a higher cost for them.
There's an argument for separate updates-testing.
However, my original point was that nobody is interested in the original
GA release set except historians. People should, and we rightly help
them, be installing updates frequently.
So, people doing network installs fall into:
People who want to install GA only: Hopefully nobody. The only good
reason to do this is if the distro is broken.
People who want to install GA+updates: Everybody except testers.
People who want GA+updates+testing: testers.
The GA package could be kept around as a separate, static repo nobody
uses under normal circumstances. Combining GA+updates into a single repo
would not consume additional bandwidth for anybody at all, and only
testers would have to do any additional configuration.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
