Another problem though, is recreating the base if you remove the patch. So say you install the base: "rpm -Uvh foo1". Then apply the patch: "rpm -Uvh foo1-patch1". This over writes the original libfoo with the new one. What happens if you try to remove foo1-patch1? RPM could refuse, because doing so would delete libfoo, leaving a broken package. It could have maybe squirreled the original away, then put it back. Or maybe request the location of the original package, and restore the needed parts from there.
Not insurmountable problems; but not as simple as just shipping patches either.
Jumping in the discussion late. What OP suggested is basically the way patches were handled in Solaris. With exception that they are not named foo-patch1, but rater 232187-06 and you are left to guess which package(s) that patch will patch ;-)
Anyhow, all the problems discussed are solvable (and are solved in Solaris packaging system). However, the real question is: is it worth the trouble implementing the (non-trivial) changes.
Both approaches have advantages and disadvantages. On one hand some bandwith is saved, but on the other hand there's complexity to it. On Linux you can always back out particular patch revision simply by reinstalling appropriate package. On Solaris, you can do the same if you had enough disk space to save backout files. If not, it is a dirty work to get rid of a patch.
I guess anybody on dialup would vote for Solaris-style patches approach any day (although those can get just as big as original packages). Most people with high speed connections would probably opt for simplicity of the way it is currently done.
How about this idea, that would be something like in the middle. Implementing a tool that could replace changed files inside binary RPM, producing new RPM (with bumped version) as output. That way you can either download a patch, or new RPM. If you download the patch, you generate new RPM by applying the patch against original distribution RPM. The only difference from downloaded updated package would be missing signature. This isn't a big deal because there were signatures on both the patch and the original RPM, and user can sign resulting RPM with his own PGP key. The rest of the patching process is the same as now (install updated RPM, either downloaded one, or the one generated using the patch).
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
