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
Virgin sources, with patches applied, built reproducibly.
So what RPM is/was designed for is a new package with patches applied
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
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
> 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
Enhances: gets into preferences are other complexities. You need/want
mechanism, not preferences.
The details of file conflicts can be addressed more carefully than
Upgrading the base package underneath a set of patches is likely
with RPM. At that point, you are better off just building
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