On Wed, 2005-06-22 at 13:09 -0600, Bart Whiteley wrote: > On Wednesday 22 June 2005 12:21 pm, Dan Trainor wrote: > > This software will not be released into the wild. It will be kept > > strictly internal to the company which I work for. > > Based on this, and the fact that you seem to grasp all the issues, I say > leverage the RPM tool any way you please. Of course people are free to abuse the tools however they please. Abuse, because "configure package interactively from rpm %post" goes right against rpm design and purpose, even if there are tricks to get around it. > > The only other danger is that someone who doesn't understand the issues, and > is building RPMs that may be "released into the wild", may see your RPMs and > copy the techniques you use. > > I've seen cases where someone builds a "bad" RPM, and later other teams use > this bad RPM as their template and soon there are dozens of broken RPMs. The > original packager may have understood the issues, and consciously made the > RPM "bad" -- like you want to, but others just copy what they assume to be a > good RPM. > > So maybe put a big disclaimer in your .spec. ;) Yep, rpm's (and practices used in them) have a funny way of finding their way to places you never expected them to be. Including things like somebody wants to install your package directly during initial system installation (eg kickstart) or such. Going around the "rpm filosophy" is certainly possible as seen in all sorts of commercial vendor packagings. The common thing to them all is that they end up biting you one way or the other. - Panu - >
