rsync and rawhide

[Jean Francois Martinez]

On Sun, 2003-10-19 at 14:26, Trae McCombs wrote:
> On Sat, 2003-10-18 at 10:32, Chris Ricker wrote:
> > On Fri, 17 Oct 2003, Kevin Fenzi wrote:
> > 
> > > Someone the other day was telling me that with updates for SuSe you
> > > could pull down all the new rpms, or just pull down changes between
> > > the updated rpm and your current version... 
> > > 
> > > Ah, there they are... called 'patch rpms'.
> > > From:
> > > 
> > > http://www.suse.com/us/private/download/updates/90_i386.html
> > > 
> > > "New: Patch RPMs
> > > 
> > > As of now we are offering so called Patch RPM packages. A Patch RPM
> > > updates an already installed RPM. It only contains files which have
> > > changed - therefore it is (much) smaller than the complete RPM
> > > package. Prerequisite for installation is an already installed basic
> > > RPM. The packages included on the SUSE LINUX 9.0-CDs/DVD are
> > > considered as basic RPMs.  If you want to update an already installed
> > > package, please download the smaller Patch RPM package."
> > > 
> > > Something like this would be very handy for keeping up with rawhide,
> > > saving redhat bandwith, and making more people use it as it became
> > > smaller/faster/easer to do. 
> > > 
> > > Anyone know how they do those? Would that be hard to implement?
> > 
> > Interesting. Looking at just one patch.rpm,
> > 
> > ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/bluez-bluefw-1.0-68.i586.patch.rpm
> > 
> > Dumping the rpm contents shows it contains just a single file (the one which 
> > needed to be changed)
> > 
> > rpm -qlp on the patch.rpm, however, lists it as containing all the files
> > which are normally in the bluez-bluefw package
> > 
> > I guess when it gets installed, it leaves the old files on, replaces the one 
> > which needs fixing, then registers in rpmdb? I wonder what happens if you 
> > rpm -e the patch? Do you go back to the original package, or do you 
> > uninstall the whole package?
> > 
> > Looking at the spec file for the rpm, I see no evidence of how the patch.rpm 
> > is generated....
> > 
> > At any rate, this on one level at least seems like a bad idea to me. One of
> > the nice things about managing Linux (versus other Unixen) is that on most
> > major Linux distros patch management and software management are the same
> > thing -- patches are just new versions of existing packages, and you
> > install, track, etc. the way you do any packages. That's better than the
> > usual "one set of tools to manage packages, another to manage bugfixes to
> > packages".... The patch.rpm's seem a bit of a step backwards, at least in 
> > that respect.
> 
> (putting this at the bottom like a good little boy...)
> 
> I know I'm not the most technically inclined person, and I know I've not
> fully followed this thread.  However, I do feel in the case of saving
> bandwidth, and making upgrades more accessible to those that are limited
> with their pipes, I think it makes sense to have a low-file-sized
> solution for those wishing to upgrade their full systems.
> 
> For instance, Let's say I've completed a full install of FC1.0 (I know
> it's not out),  and then when the next release comes, I could download a
> "patch.ISO" of roughly 300megs or so, I'm guessing(probably incorrectly)
> that this would be the difference from one version to the next.  At any
> rate, it would be nice to be able to download a patch.ISO that's one CD,
> and have it patch/upgrade your system, instead of having to download 3
> iso's.
> 
> Again, I'm sure I've missed the point, but it's my 2 pennies.
> 

The problem is that RPM is a compressed format.  Change one byte in it and
there are chances ALL the remainder of the file is different.  One thing
who is not technically impossible would be to post files containing the 
additional patches and the spec file for building the new RPM (provided
the base software has not changed.  However a thing most people don't
realize is that software building is not reproducible unless you have
a very tightly defined environment (much more tightly than in your
usual spec file).  For instance when you build the Gimp the configure 
script will check for some optional libraries (eg allowing it to
handle additional formats) if it doesn't find them
then the build will still succceed but the product will have less
capabilities.  And of course it will be a support nightmare.

I think the right answer is to get CD distributors in the bandwagon. 

			JFM