[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Can RPM handle "patch" RPM files ?
- From: "Jeff Johnson" <n3npq jbj gmail com>
- To: "RPM Package Manager" <rpm-list redhat com>
- Subject: Re: Can RPM handle "patch" RPM files ?
- Date: Thu, 1 Feb 2007 12:43:08 -0500
On 2/1/07, Jos Vos <jos xos nl> wrote:
On Thu, Feb 01, 2007 at 05:50:04PM +0100, Martin Koller wrote:
> Is there any way to solve this or is RPM simply not made for this scenario ?
The latter. You should provide new RPM's of the full product and
give them a newer version and/or release number, so that you can
upgrade with "rpm -U ...".
All true, but let's fill in some additional details.
FIrst of all, SuSE has extended RPM to handle something called "patch packages".
The implementation is perfectly sound and has been used successfully to deliver
patches to existing SuSE packages for several years as far as I know.
There is a significant complexity added to package management by introducing
"patch packages" however. The install mechanism has to apply the delta from a
patch package to files and metadata, and update the file system and
rpmdb accordingly.
The dynamic change introduced is very much at odds with other current features
within rpm, such as the abilty to preserve digital signatures on the
original metadata,
or the ability to recreate the original package using --repackage after intall.
Builds become more complex because the original, unpatched, package often
needs to be present to compute the delta. If there are multiple
"original" patches,
then each of the "original" patches needs to be present, and patch
packages between
each possible start/end point need to be built. That's a fairly large
matrix of patch
packages that potentially need to be supported. The maintenance problem gets
worse and worse whne ther are multiple patches that need to be applied
in a orderly
sequence, with (potentially) large amounts of additional metada needing to be
added to packages.
(aside) Sure there are ways to simplify the maintenance problem of original and
patch packages by saying "Don't do that." or "I don't need that.", but
the general
problems exist, no different than any version control system.
The typical reason(s) for wanting to use patch packages are usually some
variant of
Smaller is better.
often in a saving bandwidth cost of downloading a full package context (in
my experience).
Bandwidth savings are available through other means than patch packages. Try
rsync, or xdelta or rdiff or any other deltafication scheme on the
package itself, not
by patching the file elements contained within the package.
73 de Jeff
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]