Proposed F13 feature: drop separate updates repository

[Ralf Corsepius]

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