On 12/02/2009 06:40 PM, 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.
Yes, for people who are doing "full featured networked installs" w/
custom kickstart files. I've never met such a person.
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.
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.
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.
On the other hand, the content (the packages referenced inside) of
"updates" overlaps with packages in Everything
=> The number of packages to be considered in dep-computation should
become much (?) smaller. However, I am not knowledgable enough with
yum's internals to estimate the impact this would have on
turnaround-times, memory and diskspace requirements this would have on yum.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
