Les Mikesell wrote: > Robert Moskowitz wrote: > >> >> >>> If you can build the RPM, you do have access to the spec file. If >>> you're building directly from a .src.rpm with rpmbuild, it's embedded in >>> the .src.rpm making things a little tougher. Best is if you're building >>> from some kind of source tree and so have the .spec file right there. >>> >>> >> I am building from some kind of source tree, so I await the developers >> help. But you here have given me some direction to push them to 'do the >> right thing'. >> > > Are you just moving ahead in the upstream development? If so, just > using appropriate version numbering should do the right thing. > Upstream development? DOn't quite get the reference. The developers showed me where the spec file is and I have changed the release entry to append the current patch number. Will see how that goes... > >> I am the first one on this project that is installing the code on a >> number of systems, many of which are a little anemic (www.oqo.com) for >> doing compiles on a daily basis. And generally want to move usage to a >> more production framework. >> > > If you have a bunch of machines you probably want to set up your own yum > repository for subsequent updates and build an rpm to install the repo > url and its GPG key. > Basically what I am doing. > >>>>> On the other hand --replacepkgs or --oldpackage might work. >>>>> >>>>> >>>> This must require some yum plugin??? as --replacepkgs is not documented >>>> on my systems, nor does it work. >>>> >>>> >>> These are rpm options, not yum options: >>> >>> rpm -Uvh --replacepkgs my-custom-thing-1.0-1.i386.rpm >>> >> oh. of course. So now I install the downloadonly yum plugin.... >> > > That should be the first thing anyone does if they need to baby-sit > updates or reboot at appropriate times anyway, but if the version > numbers are bumped the files should update in a normal yum run. Trying to get things to work normally in yum, so I can make this more 'globally' available.