Re: Binary RPM patch packages versus Windows SP style

[Enrique Perez-Terron <enrio online no>]

On Thu, 2004-08-26 at 22:58, Robert Vojta wrote:
> Hallo all,
> 
>   this is reaction to the email with this subject "Request for comments on
> binary RPM patch packages".
> 
>   My opinion is that this idea is good but binary diffs are too difficult to
> implement without any side effects like patch packages are allowed to be
> in the system even if we are removing original package, etc.

No, I don't think it is too difficult.

Assume package A.rpm has been distributed and installed on a number of
computers. A new package B.rpm has just been created, which updates A.

Step 1. 
Computers where "rpm -V A" produces no output, have "uncorrupted
installs" of package A. Then no files are missing or corrupted. Files
marked as configuration files or user-modifiable files can have any
contents whatsoever.

Create a file "A.quasi-rpm" based on information available on all
computers having an uncorrupted install of package A. It is not strictly
a goal that the quasi-rpm file is actually usable as an rpm. The goal is
to find a procedure that yields the exact, byte for byte same result on
any such computer, and such that the file produced resembles an rpm
where this is easy. For instance, the provides and requires information
should be stored in the same way as in real rpm files.

Some rpms are reloactable. The local relocation prefix should not appear
in the quasi-rpm, as this will vary from installation to installation.

Rpm files contain cpio archives. A quasi-rpm contains a cpio archive
where the user-modifiable members are replaced with empty files.

Step 2. 
Create a binary diff file that is a recipe for creating B.rpm from
A.quasi-rpm. Call it "B-from-A.rpmpatch". Distribute this file

Step 3.
On a target computer with package A installed, generate "A.quasi-rpm"
locally. Run 
   # rpmpatch  A.quasi-rpm   B-from-A.rpmpatch  -o B.rpm
   # rpm -U B.rpm

Advantages: 
 - No changes to rpm.
 - Only normal rpms are actually installed.
 - No insane dependency confusions like the patch rpm remaining 
   installed when the base rpm has been removed.
 - High integrity guarantees. The B-from-A.rpmpatch file contains an MD5
   sum of the target B.rpm.  If anything goes wrong, and the B.rpm
   produced fails to have this MD5 sum, rpmpatch deletes it and issues a
   suitable error message.
 - It is possible to generate X.quasi-rpm directly from X.rpm, without
   first installing X.rpm
 - It is possible to write rpmpatch such that it can apply a sequence of
   patches, i.e., the intermediate rpms are reduced in-place to
   quasi-rpm format.
 - Distributors can disseminate patches against the rpms in the ISO
   images. Users wanting to install the latest version of a package need
   not first install the package from the CD-ROM. They can generate the
   quasi-rpm from the rpm on the CD, and then generate and install the
   latest rpm.

What do you think?

Regards,
Enrique