Request for Comments: updating RPMs using binary deltas

[Jef Spaleta]

I'm going to combine a couple Lamar Owen's previous post quotes here as
a way to streamline my response to him.

Lamar Owen wrote:
>In the ultimate realization there would be no 'fully cooked' updates
>The mirror would keep the original distribution files (just in case
>someone needed them) and the update patches.

Now...here's a wrinkle in your plan. Maybe you are not aware, and I
myself had to be reminded of this fact....in the past Red Hat has had to
respin isos for non-technical reasons. In the past the box sets isos
that have come out have ended up having different packages (but the same
package versions) because of things like legal reasons. The isos that
have gone to the mirrors had to be corrected, for non-technical reasons,
and ended up differing from the boxsets media that was produced in
advance of the actually distribution release date. That's a problem for
your plan...having multiple versions of what could be considered an
official distribution release. And frankly, since these respins in the
past have been for non-technical, dare I say legal, issues there is
never going to be a grantee that Fedora Core iso images are going to
need to be redone a few days after the release date. The legally tainted
iso images MUST be taken out of circulation, and the legally correct
isos and images must take their place. Your rpmdiff idea can not CLEANLY
take care of this sort of problem. Since its going to be difficult to
cleanly define the true original package for people who grab the legally
tainted release before it was purified. Its nice to dream that this
situation won't keep coming up...but its perfectly realistic that there
will be licensing and patent issue that don't get caught in testing and
someone out in the wild makes Fedora aware of the violation after the
official isosets are pushed. How do you push rpmdiff updates for
packages that have the exact same versioning numbers and are considered
offical and are signed by the same key? Start adding md5sum information
of the base package in the package name scheme?
Let's hope we don't have to test that sort of situation out with
something like a legal challenge in the US for the mono project on down
the line.

[ from another post in reply to another post from me ]
> When updates exceed 100MB _ALL_ users are low bandwidth, and dialup 
> users are locked completely out.  So they don't update at all, get 
> hacked, and blame Linux.

There is an argument to be made that users shouuld expect to utilize the
same networking methods to get updates that they used to get isos.
Whether that network is broadband or sneakernet or their friends
stationwagon full of punchcards or even homing pigeons. 
 
> Absolutely.  I would think mirror operators would love to reduce the 
> load on their servers, which this would as I've envisioned it.  And 
> their bandwidth bill might even go down.

I'm pretty sure seth is a mirror operator...
http://www.redhat.com/archives/fedora-devel-list/2004-January/msg00483.html

But maybe he didn't realize you meant to do this as part of the
all-powerful buildserver. I'm making popcorn in preparation for watching
more discussion from seth on this issue.

And i want to comment on making this a replacement and not providing the
fully baked rpms, you have to create the full update rpms to get the
diffs, so they have to exist, and they really need to be available as
part of a transparent process so people can verify the rpmdiff is
reintegrating the rpm correctly. Because reintegration for some people
WILL not work for them at some point, now you can come into #fedora irc
chat room at any time and try to explain to them that it SHOULD work
everytime for everybody...but users have an amazing ability to create
their own problems..that you didn't expect to see.

-jef"So...i wonder why noone has taken the time yet to attempt to build
the equivalent full set of rpmdiffs for ALL the published rhl 8.0
updates and started actually benchmarking this concept in a general use
case for a full lifetimes worth of updates..working with both original
boxset isos and the respun downloadable isos..and find an interested
mirror maintainer in the fedora core mirror list already and actually
start benchmarking how this is going to work in general use cases....we
been talking about this for what a whole day now....but I'm happy to
keep talking about...because i'm certaintly not interested in
implementing it myself"spaleta