>This makes future maintenance easy, preserves the pristine source >(which is the third-party RPM in that case), etc. > >Lots of third-party RPMs (especially those of *huge* companies) are >crap and show those people do not understand what RPM is meant for. >Especially dropping everything in some directory and have a >multi-thousand-line %post script to actually install the stuff (the >last RPM I looked at from EMC had a 2900+ lines (!) %post script) >seems to be a popular method :-(, thus throwing away most of the >system management advantages RPM offers you. often in these situations the vendor has some sort of homegrown method for install that works across multiple operating systems and they don't have much inclination to learn rpm (or dpkg) to accommodate just Linux. When pushed to use rpm they may do as Jos suggests - use rpm as a kind of bundling format instead of as a management format. Although I'd not seen anything quite as ugly as the one mentioned above :-) >From experience, the Intel compilers (yeah, I work for Intel but that's not my area) only partly use rpm as they have to ask some questions up front, which would violate the non- interactive-install requirement of rpm. Since these are pre-install type questions, the first-run-after-install script trick doesn't work out, so the distribution itself has a shell script you run rather than invoking rpm manually. Might be worth feeding back some bugreports that this "fix things up in the script" kind of behavior is not ideal for manageability. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
