= Proposal topic =
I would like to propose that FESCo consider making yum-presto a default package
= Overview =
yum-presto has been available in Fedora for a long time and delta RPMs have been officially supported since Fedora 11
http://fedoraproject.org/wiki/Releases/FeaturePresto
However Fedora 11 did not include yum-presto by default and majority of users did not benefit from this feature.
= Problem space =
We push a enormous amount of updates and while there are other plans such as https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience to improve the user experience, yum-presto would speed up the downloads by a large amount by reducing bandwdith usage (typically over 80%)
There has been some opposition on the basis that a few users wouldn't benefit if they are using a slow computer from a high speed connection since yum-presto would build the full RPM packages on disk which has a higher CPU consumption but I believe that majority of users would benefit from having yum-presto as a default package.
There were two problems recently cited (endianness issue as well as the higher CPU consumption due to the default compression level (6)). The default compression level set in redhat-rpm-config is now 2 (same as openSUSE) and endianess issue has been fixed upstream and the fix has been inherited in Rawhide (Fedora 12) as of yesterday.
Majority of GNOME and KDE users will get yum-presto by default anyway. I have added yum-presto to the GNOME desktop comps group on behalf of the desktop team and KDE SIG has added it to their Live CD kickstart file. yum-presto is used by a large number of users ever since unofficial repositories were made available and even more since Fedora 11 and now in Rawhide (Fedora 12) so it is widely tested already.
= Solution Overview =
Make yum-presto a default package.
= Active Ingredients =
Modify one of the base comps groups to make yum-presto a default package
= Owners =
Rahul Sundaram sundaram@fedoraproject.org, irc nick: mether
I agree with this proposal, assuming the issue with noarch packages gets fixed in time for the F12 release (otherwise I'd have to suggest dropping yum-presto from our live spins instead).
Some more rationale: It doesn't make sense to add yum-presto to the gnome-desktop (as is currently done) and kde-desktop (as was suggested too) groups. It has absolutely nothing to do with desktop environments. Adding it to the live CD kickstarts (as we did for KDE) is more tolerable, but then it should be in the base live CD kickstart, not in individual ones, and that also won't help DVD users. The right place for it is really one of the base comps groups.
Just to clarify, the noarch/endianess issue is fixed already as indicated in the description of my proposal.
https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00301.html
The fix was indeed built in dist-f12-updates-candidate, but no tag request was filed yet, so it is not in Rawhide nor in the buildroots at this point. The bug is only resolved when the package gets tagged!
Replying to [ticket:256 sundaram]:
Majority of GNOME and KDE users will get yum-presto by default anyway. I have added yum-presto
Is that not enough? I'm slightly confused why you're filing a ticket to make this the default after you have essentially done already that.
I don't think it is essentially the same thing. A large number of users would get it out of the box with the current configuration but not all of them. A considerable number of users who use the DVD and select KDE or use Xfce, LXDE or something else. Finding consensus was problematic earlier and there was a few hiccups in between but now that the dust has settled, I think placing it in a base group is a better solution as well.
Is that not enough?
It's mainly the '''wrong''' solution. yum-presto has absolutely nothing to do with GNOME, so why is it sitting in the gnome-desktop comps group? Users should get it by default even if they don't install a desktop environment at all, and installing GNOME after the fact should not add yum-presto if the user didn't already have it because it has nothing to do with GNOME. (That's why we put it in the live CD kickstart instead for KDE, but that means that people who install with only KDE from the DVD won't get it. And the KDE live CD kickstart is not a good place either, if we put it in live CD kickstarts, the right place would be the base live CD kickstart which everything inherits.)
The place for yum-presto is in the base comps group, not in *-desktop.
I personally didn't want to include yum-presto by default on the Xfce spin for a variety of reasons. However, making it the default shouldn't affect that, as we can -yum-presto in the Xfce kickstart I would think if we still don't want it there by default.
So, no objection from me off hand.
Should we talk about this at the meeting tomorrow?
b/c I'm on fesco I figure I'll comment here:
I'm officially non-committal.
this is a firm +0 to the proposal from me.
It's also a -0.
just so we're clear.
Seth -
Let me frame the question another way, because I don't like '0' answers :)
Is there any reason not to have yum-presto by default? You're the one with the most exposure to the yum codebase of any of us, so if there's a reason not to use it, we'd like to know :).
Kevin - why not on the Xfce spin - I think I know, but just wanna confirm :).
oh cmon jon, you know I can phrase the question the other way, too.
with the Xz issue fixed I do not believe presto will cause dragons to burst from the displays of our users.
how's that?
ok, third times the charm for this comment.
(Sidenote: man does trac suck. The first time I typed in a comment and then it went to a page saying someone had modified the ticket, sorry. It also helpfully disabled my back button. Second time it just ate the comment and didn't show it at all).
Many people who are pointed at the Xfce spin are on lower end hardware or are resource constrained. Not only older heardware, but many newer netbooks.
On these platforms presto is a bad idea. They have slower disk and cpu and it takes a LOT longer to apply updates. For example here I have a eeepc 900a. 512mb ram, 900mhz celeron cpu, and dirt slow 4GB SSD. On this machine updates that would normally take 10min to apply take about 1.5 hours or so of 100% cpu and disk thrashing.
So, I don't care if we think it would be good for the majority of users, but there are some cases where it's not.
FYI, the xz build which fixes the "noarch bug" got tagged and hit the 20091008 Rawhide. So there aren't any major technical obstacles anymore.
This proposal was accepted, with the condition of plenty of documentation on the change and how to disable it.
Log in to comment on this ticket.