Some large packages are composed of a large number of files. A patch package would be able to add, remove or modify files in a package while keeping the RPM database in a consistent state (owning packages, md5sums and so on). For a similar system, look at the SysV package manager on Solaris (and others).
This is unlikely to ever occur in rpm, due to the way rpm works. The "rhmask" package exists already, but that doesn't enter the realm of what you're asking really. Personally I don't see a clean way of implementing this that doesn't cause a lot of package maintenance problems, as well as multiply the potential problem permutations. Then again, I could be smoking pencil shavings. Whadda I know. Maybe Jeff is working on this right now as we speak...
Bug 7121 is being closed because it is a feature that doesnt look to be within the RPM philosophy. On Tue, Jan 07, 2003 at 02:43:33PM -0500, brandon chubb wrote: > Suppose you're creating a commercial product for Linux, and > want a system of releasing patches. What's the preferred method? > > I was happy to see 'rpm -U/-F' but it doesn't quite do what > I want. I want to be able to make an rpm patch that's sparsely > populated to only replace objects that need patching, not the > entire product. I realize that rpm -U/-F will only replace > what's changed, but why pack up what the customer doesn't need? > (And of course it will remove all the files that it doesn't contain > assuming its got the same base name.) > > The alternative is to name the patch package something different, > say have foo1.0.0-1 for the product and foopatch1.0.0-1 for > the patch train. And just let the customer run rpm -i on each > as its released. But that means removal of a series of of these > things upon a major upgrade -- kind of messy. > > Am I missing something, or does rpm not deal with sparse (binary) > patches very well? rpm deals with packages, not patches, nor files. If you want patch management, rpm is not the implementation of choice. 73 de Jeff