On 2/1/07, Jeff Johnson <n3npq.jbj@xxxxxxxxx> wrote:
On 2/1/07, Jos Vos <jos@xxxxxx> wrote: > On Thu, Feb 01, 2007 at 05:50:04PM +0100, Martin Koller wrote: > > > Is there any way to solve this or is RPM simply not made for this scenario ? > > The latter. You should provide new RPM's of the full product and > give them a newer version and/or release number, so that you can > upgrade with "rpm -U ...". > All true, but let's fill in some additional details. FIrst of all, SuSE has extended RPM to handle something called "patch packages". The implementation is perfectly sound and has been used successfully to deliver patches to existing SuSE packages for several years as far as I know. There is a significant complexity added to package management by introducing "patch packages" however. The install mechanism has to apply the delta from a patch package to files and metadata, and update the file system and rpmdb accordingly. The dynamic change introduced is very much at odds with other current features within rpm, such as the abilty to preserve digital signatures on the original metadata, or the ability to recreate the original package using --repackage after intall.
Additionally, ATM, rpm does not to my knowledge handle rollbacks of patch type packages. I've though through some of this and it is a mess (albeit it could be done, but much work would have to be done for that to be possible). Actually the sanest possible thing that could happen would be for the patch package to have the header of the end package, such that after your done there was no sign of a patch. The original package would be repackaged as normal, and a rollback would be succeful. The signatures should be OK, provided your patching a system that really had the begin package installed...oh, but what if you mess up? Well that is mess. Maybe then its better to generate the patch on the fly across the network. This can work, but not for all consumers. So, IMHO patches typically cause more perturbations to the configuration management matrix than I personally like to see or think about...which is why I typically suggest a more KISS method of smaller sub packages. Cheers...james _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
