On Thu, 2009-10-01 at 08:41 -0400, Richard Ryniker wrote:
> > it's a simple way to compare whether the delta RPM thing is saving you
> > any time. If that speed is faster than your download speed, it is...
>
> Do you mean there is a parameter a user can employ to control the balance
> between network and processor resources for an update?
No, I hope I didn't suggest that as it's not what I meant. :) You can
only turn delta usage on or off, there's no 'control' over the process.
> I surmised the
> object of the delta strategy was primarily to reduce data traffic at the
> servers, with a secondary benefit of faster delivery to users with
> small network bandwidth.
Both goals are considered important, AFAIK.
> I have found the rebuild speeds displayed on my F12 test system
> one-quarter to one-tenth of my network bandwidth. This has not been
> onerous, but certainly time would be saved if I could say "Do not use
> delta rpms." to yum.
See comment about the too-high compression level used.
> Recent experience has delivered the worst of both worlds: about half the
> delta rpms fail integrity checks, and complete copies of those files have
> to be downloaded after the delta rebuild failures. An earlier post to
> this list explained a format change causes these failures, and they will
> abate as packages are rebuilt.
I'm not sure we've actually dealt with that problem in any way yet,
though we've spent lots of time arguing about it...it's not about a
format change, exactly, the problem is that xz doesn't produce the exact
same compressed output on PPC architectures as on x86 architectures, and
some noarch deltaRPMs were/are being generated on PPC buildhosts, so
when they come to be reconstructed on x86 hosts, the check fails...there
are various ways this could be addressed (stop building noarch packages
on PPC buildhosts, adjust xz so it doesn't have this particular arch
difference any more), but as usual the -devel list took it as an excuse
for a good old 'robust discussion' about whether xz was evil and what
would be the really really really correct way to fix it ('but either of
the simple and obvious fixes are just band-aids and don't fix the real
underlying problem that xz is evil!'), rather than actually dealing with
the problem first. good times!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
