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.