On Sat, Nov 7, 2009 at 1:58 PM, Jeff Johnson <email@example.com> wrote:
> 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
> not a base package, with patches applied on end-user machines.
This I can definitely agree with. Of course, in my situation I'm not
in control of the application side -- I was recently brought in as a
Linux admin, and one of the items I identified is the lack of proper
package / patch management for my companies application.
> OK, so some subset of patches needs to be applied on a per-customer basis.
> 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.
I was thinking something along this line. The app gets installed in
/usr/appname, and the patches package gets put into
/usr/appname/available_patches. A simple interface could then be used
to selectively copy files from specific patch sets and execute post
install scripts. Only problem is that when you later do a verify on
the original rpm package, it would show up as corrupted (unless I mark
all the files that are likely to change as "config" files).
> 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).
Just to give you a bit more background, the application we put out is
to control a set of medical devices (lab analysis equipment). And
once it is working at a customer site, they generally don't want it
changed unless they request a specific feature or bug fix. So what
ends up happening is a feature is added, and the developers then put
it aside and make it available to any other customer asking for
Of the two approaches above, I'm not sure which would be the best way.
I like the idea of the package manager keeping track of dependencies
(every once in a while a patch requires a previous patch to be
installed). But here's where it gets tricky. Patch 27 might not
depend on patch 15, however if 15 is installed then 27 may do a
different post install (such as adding tables to the database -- no
need to add them if a previous patch already ran that step). So if 15
isn't installed, 27 will carry out a step. But if 15 is installed,
then 27 is installed, you will have a problem if you remove 15 because
the uninstall script for 15 will remove a table that both it and 27
depends on. So I'd need to have the meta data in the RPM database
reflect that 27 depends on 15 only if 15 was there when 27 was
(yes that sounds a bit more complicated than a typical scenario, but I
figured I should have all possible bases covered).
Ok, so here's a thought. Is it considered bad form for a package to
further manipulate the RPM database directly in the post-install
script? If that is acceptable, then I was thinking of something like
this: The main package (appname-version-subversion) gets installed,
then when a "patch" package gets installed (preferably as an RPM, but
not required) it modifies the parent packages meta data so that it
becomes the owner of any new files (and the MD5 sum gets updated for
any changed files). As a secondary action, since the parent app is
technically a new (unique) version, the version-subversion part of its
meta data could then be modified to reflect the current set of patches
installed (say as a hash of all the patch versions that are
Of course, the more I think about it, this might be easier using the
idea that you mentioned of having a parent app, and a "patches" rpm
with a custom interface for activating / deactivating each patch.
If you have any other ideas, I'd really appreciate it.
Received on Sat Nov 7 22:45:31 2009