Hey guys, first thanks for your quick and helpful responses! Hm, its not the first time i asked here and i always got treated this way :) Thank you. * Tim Mooney wrote: > In regard to: RE: post post installation hook, James Welch (jimwelc) said...: > > If Lars doesn't have control of the spec file, it's possible that a vendor > is involved, in which case there may be an opportunity to report the bug > (and it is a bug) to the vendor. Well, to give a little bit more context. I have the pleasure to refactor a quite large and ugly app mostly written in perl. The app was and still is under development for a few years now. The devs before didn't use any kind of version control, bug tracking or what not. No regression tests or anything. The app is used in productive environments on quite a few sites of our customers. I have full control over the specfiles and all that as i am the only developer atm. Mostly doing main surgery on that things build environment atm, well there was not really an environment anyway. Actually, except for the difficult code base, i am thinking that this thing does its job and does it quite well. Therefor i am hoping to bring the code base and build environment back in shape. Problem is that there are earlier versions rolled out which have for one reason or another be replaced with newer versions of the app. I have to figure out an upgrade path now and one problem i stumbled over is that an earlier installation has this bug mentioned in my first post. Thats the reason why i am looking for a way to circumvent this behaviour of the the earlier versions post-uninstall scriptlet. So to rephrase my problem. I have an app with version A and a newer version A' of the same software. The never version here means a new major release. Version A has a defective post uninstall scriptlet but the problem now is that i can not just walk onto the customers site and tell them oh bad luck we have a new version out the door but the upgrade might not work for you ... no no It has to work[tm] without any complications for our customers. Normally i would use yum upgrade <package> as this also takes care of handling dependencies. So i hoped that there was some final scriptlet that could be used for mitigating the behaviour of version A. But i have to be careful to not make the next upgrade after A' such an interesting undertaking again. So i think, as some of you suggested, i will modify the installer and use the -nopostun flag with rpm or use a triggerpostun scriptlet. Especially the triggerpostun scriptlet looks interesting as it allows me to specify the version of a package i want to get it executed on. regards --lars _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
