RPM Community Forums

Mailing List Message of <rpm-users>

Re: Creating patch rpms

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 07 Nov 2009 - 20:58:31 CET
Message-id: <9F3BFF38-B262-4462-94C7-5868E108F755@mac.com>

On Nov 7, 2009, at 2:01 PM, Derek Pressnall wrote:

> I've got a packaging issue I'm trying to resolve.
> Our application consists of a several hundred files (mostly input
> forms and sql files).  Periodically the developers release patch sets
> to add specific features or resolve issues, which consists of about a
> about a dozen or so files.  These files are either in addition to, or
> replacement of, files that are part of the original application.

OK. Please note that distributing patches, while a perfectly common
and useful methodolgy, is fundamentally at odds with RPM's original
design goals:
	Virgin sources, with patches applied, built reproducibly.
So what RPM is/was designed for is a new package with patches applied  
during build,
not a base package, with patches applied on end-user machines.

But I can tell you what to do to distribute patches in a package to be  
applied to
a previously installed "base" package on end user machines.

> Now normally with RPM, you would release a new package version and use
> that to update the previous version.  The problem is that customers
> each get a unique set of these patches (one customer may get patches
> 1, 17, and 25, while another will get patch 8, 17, and 31).  Now what
> I'd like to do is install the main package rpm, then roll out an rpm
> for each patch set (and use RPM's dependency tracking to force
> dependent patches to be installed).  But the problem comes in that
> many of the files included in the patch sets conflict with existing
> files in the parent RPM, which would require the --force flag to be
> used.  Furthermore, it would show the parent package as having corrupt
> files (since the new files are owned by the patches).

OK, so some subset of patches needs to be applied on a per-customer  

Likely the easiest packaging is to have all patches in a single package,
updated whenever there are new patches. Likely just as easy is a package
per-patch, and have the customer choose packages/patches to apply.

Which model fits you best:
	All patches distributed with configurable sub-set application.
	Each patch in a separate package, and a subset of all patches is  
	(i.e. applied).

> Is there any to package a set of files and tell RPM that it "enhances"
> another package, so it would a) let you install it despite conflicts
> (without --force), and b) keep the parent package & children packages
> grouped together (so that when the parent package is upgraded, any
> patches included with the new version get removed from the RPM
> database)?

Enhances: gets into preferences are other complexities. You need/want
mechanism, not preferences.

The details of file conflicts can be addressed more carefully than  
using --force.

Upgrading the base package underneath a set of patches is likely  
with RPM. At that point, you are better off just building  
reproducibly, i.e.
patches are applied while building, not on the end-user system.

I can describe some approaches to distributing patches in packages once
I hear what your constraints are.

73 de Jeff
Received on Sat Nov 7 20:59:00 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.