No deltarpms in Fedora 11
Posted May 4, 2009 16:23 UTC (Mon)
by wtogami (subscriber, #32325)
[Link]
Posted May 4, 2009 16:25 UTC (Mon)
by kragil (guest, #34373)
[Link] (6 responses)
A big part of that is IMHO making the ridiculously large sqlite db that has to be downloaded with every change more modular. One for the base packages, that does not change, one for security updates and one for bug fixes/enhancemnts.
Just my .02 , though.
Posted May 4, 2009 16:31 UTC (Mon)
by lkundrak (subscriber, #43452)
[Link]
Posted May 4, 2009 17:01 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
Now for updates..I'm not sure we can get more modular than that without impacting dependency resolution. The security updates and the bugfix/enhancement updates aren't built such that one group layers over the other. Security updates can and will depend on previous updates which were listed originally as enhancements and vice versa. Even if you are using yum-security plugin and use a local policy that only updates packages tagged as being security relevant at time of release...you will still pull in bugfix and/or enhancements to fill deps on occasion.
-jef
Posted May 4, 2009 20:55 UTC (Mon)
by cyperpunks (subscriber, #39406)
[Link]
Yes, we can.
Consider late in Fedora 10, primary.sqlite.bz2 is 3.3MB. Now add a single package, the whole primary.sqlite.bz2 must be downloaded again with 99.8% identical content, while some tiny SQL statement would be enough to update the sqlite file to correct state. Should not be impossible to implement this idea. Any takers?
Posted May 4, 2009 17:59 UTC (Mon)
by nevyn (guest, #33129)
[Link] (2 responses)
Release and updates are already separate. Separating security vs. other might be interesting, but would require a lot of work on the server side to make sure depsolving still worked. Another fix might be to turn down the firehose :).
Posted May 4, 2009 19:36 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
There is a real tension between use cases when it comes to update policy. The current updates policy isn't perfect, but its rather simple in practise and it boils down to trusting the package maintainers to make their best judgement for the packages they maintain on behalf of their userbase in coordination with upstream project developers. Anecdotally, I've yet to run across user who wants to see less frequency in updates for the packages I maintain (and yes I know I have at least one other user beside myself for each of them :->).
Fedora's got something like 800+ active package maintainers if memory serves, more than half external to Red Hat. They each use their best judgement when it comes to bugfix and enhancement updates. Who's qualified to tell those maintainers they aren't making the best choices for best overall benefit to the userbase of those packages?
Adding complexity by restricting what maintainers are allowed to do with regard to official updates and building a house of cards of semi-official addon repositories for enhancements or bugfixes just makes everything more complex with little benefit to the core mission of Fedora.
-jef
Posted May 4, 2009 20:20 UTC (Mon)
by nevyn (guest, #33129)
[Link]
Posted May 4, 2009 16:25 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
-jef
Posted May 4, 2009 16:30 UTC (Mon)
by stickster (guest, #40146)
[Link] (3 responses)
Posted May 4, 2009 16:45 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
And to be clear having it enabled in rawhide is a HUGE benefit to testers. With the amount of churn in rawhide on a daily basis, I can't always keep up on my relatively slow residential connection. Deltas will help a lot. I'll make it easier to keep a dedicated rawhide system running at home. Instead of just virtual systems running on iron at work.
-jef
Posted May 4, 2009 20:44 UTC (Mon)
by cyperpunks (subscriber, #39406)
[Link] (1 responses)
Posted May 5, 2009 4:57 UTC (Tue)
by lkundrak (subscriber, #43452)
[Link]
Posted May 6, 2009 13:01 UTC (Wed)
by pranith (subscriber, #53092)
[Link] (1 responses)
Missing from conversion
No deltarpms in Fedora 11
No deltarpms in Fedora 11
No deltarpms in Fedora 11
No deltarpms in Fedora 11
> impacting dependency resolution.
Re: No deltarpms in Fedora 11
Re: No deltarpms in Fedora 11
Re: No deltarpms in Fedora 11
No deltarpms in Fedora 11
No deltarpms in Fedora 11
No deltarpms in Fedora 11
No deltarpms in Fedora 11
No deltarpms in Fedora 11
No deltarpms in Fedora 11