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 _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
