[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Proposed F13 feature: drop separate updates repository



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]