On Nov 7, 2009, at 4:39 PM, Derek Pressnall wrote:
> On Sat, Nov 7, 2009 at 1:58 PM, Jeff Johnson <firstname.lastname@example.org> 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
>> Likely the easiest packaging is to have all patches in a single
>> updated whenever there are new patches. Likely just as easy is a
>> 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).
There's a %verify(...) attribute that will disable --verify checking
of specific attributes. But its likely just as important to keep track
of which files in base a package has modified, the same disabler
can be done from the RPM CLI when using --verify too.
%config is likely (generally) not what you want.
One could also use alternatives, and install every file on
separate path, with a symlink to choose whatever alternative
is actually used, but that's likely a fair amount of pain to
get into place with hundreds of 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
> something similar.
K. SO a "customer pull" patch distribution model, much like SunOS used
> 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, if every patch is in a separate package, one could add dependencies
on precursor patches. And users seem to understand choosing packages,
more complicated choices or configuration management is often
But there are also applications where you deliberately want a
way to prevent destabilizing an application needlessly, its a bit too
easy to (acidentally or otherwise) uninstall packages sometimes ;-)
> (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
This is what I call a "package bundle". WORKSFORME, YMMV, and there
are many who will lecture you on the error of your ways if you try
a "package bundle" approach.
Modifying the parent packages metadata just ain't gonna happen, the
metadata is (at a minimum) digest protected, so modification will
always be detected and will always be failed.
Alternatives is likely a better way to achieve modifications, the
patch package could set a new/better alternative, basically a different
symlink, to a unique install location.
> 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.
There's lots of ways to make skinny cats ;-)
BTW, is this @rpm5.org RPM or something else. If @rpm5.org, there's
significantly more ways to make skinny cats ;-)
73 de Jeff
Received on Sat Nov 7 23:06:20 2009