On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: > > 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. > Yes, for people who are doing "full featured networked installs" w/ > custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. Any sizable deployment of Fedora/RHEL uses or should use kickstart. And those that don't aren't afraid to check that little 'updates' box at the software selection screen. You seemed to have ignored that part of my point. > > > In fact, having separate repos would likely cost less bandwidth. If we > > only had one combined repo, there would be many duplicate packages, > Where? Unlike now, where you have each package twice (in Everything and > "updates"), you would have each package only once: In Everything. That assumes we purge anything but the latest version of a package, which as noted in other parts of this thread gets complicated with GPL compliance. > > It would help people like me, who are locally reusing downloaded > packages in a networked environment, instead of letting each machine > accesses the original repos directly. Surely a caching proxy server doesn't care what folder a file comes from, it'll cache it. Whether the new file shows up in Everything/ or the new file shows up in updates/ shouldn't matter. > > > especially if we went the route of having updates-testing mixed in and > > only marked by some update tag. > Updates-testing is an add-on repo to "Everything+updates". > > A merged new Everything would not change anything wrt. > "updates-testing". The only difference would be packages being pushed to > "Everything" instead of "updates". > > > 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. > Your concern is the bigger repodata? > > Reality check: > # ls -h -s releases/11/Everything/x86_64/os/repodata/*.sqlite.bz2 > updates/11/x86_64/repodata/*.sqlite.bz2 > > 16M > releases/11/Everything/x86_64/os/repodata/0301ed1cbf01c00cdf9c42b71df6c74947d9c76a3c9767e8f85a99ef6fdccb86-filelists.sqlite.bz2 > 11M > releases/11/Everything/x86_64/os/repodata/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite.bz2 > 5.8M > releases/11/Everything/x86_64/os/repodata/d3405c970a0c27e9dc3fd3ed179af33fee9a72bf704f45f1ed96a9063b40d7c7-other.sqlite.bz2 > > 9.0M > updates/11/x86_64/repodata/3a725e07adff9d7e56e7fd8bd3091f38107723987b3b614220df72494dc6814d-filelists.sqlite.bz2 > 6.0M > updates/11/x86_64/repodata/54ca116c2a00e87eaca6491adb9e077f4d3f0d5b20e7cbab984774aefb042d0f-primary.sqlite.bz2 > 3.2M > updates/11/x86_64/repodata/646eb24cfe113de569853a4e05f55773b3ad9531dee646e7d843b8dc4a849780-other.sqlite.bz2 > > => An estimate for the increase in downloaded files's sizes you are > talking about is ca. factor 2, from 18.2M (current "updates") > to 32.8M+ (current "Everything"+"newly introduced packages) > > > Whether this increase in download-size is "significant" is up to the > beholder. For me, it gets lost in the noise of accessing a "good" or a > "bad" connection to a mirror and in the time required to download > packages from mirrors. 33~ megs downloaded every single time an update is pushed is a significant hit for a fair number of people. That was why it was important to make yum not re-fetch that repodata every time, and use a cached version of it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
