I have to build my own rpms for the HIPL project. I update my copy of the code and make rpm.
Thing is the rpm name never changes from patch to patch.
Is there a way to have yum apply the new code as an update and not have to erase then install?
Robert Moskowitz wrote:
I have to build my own rpms for the HIPL project. I update my copy of the code and make rpm.
Thing is the rpm name never changes from patch to patch.
Is there a way to have yum apply the new code as an update and not have to erase then install?
Do it the correct way and update the spec file, so that it at least gets a new release?
On the other hand --replacepkgs or --oldpackage might work.
Ralph
Ralph Angenendt wrote:
Robert Moskowitz wrote:
I have to build my own rpms for the HIPL project. I update my copy of the code and make rpm.
Thing is the rpm name never changes from patch to patch.
Is there a way to have yum apply the new code as an update and not have to erase then install?
Do it the correct way and update the spec file, so that it at least gets a new release?
For this I will have to work with the developers to find out where the spec file is and how to change it without breaking something (or get them to change it!).
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.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Robert Moskowitz Sent: Monday, December 08, 2008 12:14 To: CentOS mailing list Subject: Re: [CentOS] New rpm, same name, how to update
Ralph Angenendt wrote:
Robert Moskowitz wrote:
I have to build my own rpms for the HIPL project. I
update my copy
of the code and make rpm.
Thing is the rpm name never changes from patch to patch.
Is there a way to have yum apply the new code as an update and not have to erase then install?
Do it the correct way and update the spec file, so that it at least gets a new release?
May I suggest the rpm mailing list?
http://lists.rpm.org/mailman/listinfo/rpm-list
rpm-list@lists.rpm.org
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
Robert Moskowitz wrote:
I have to build my own rpms
For this I will have to work with the developers to find out where the spec file is and how to change it without breaking something (or get them to change it!).
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.
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
Warren Young wrote:
Robert Moskowitz wrote:
I have to build my own rpms
For this I will have to work with the developers to find out where the spec file is and how to change it without breaking something (or get them to change it!).
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'.
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.
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....
No get the developers to fix the source tree's spec file. The SIP Communicator team is doing their daily rpms with the patch number (or is it the date?) in the rpm name, so this gang can also 'do the right thing'.
Thanks all!
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.
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.
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.
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.
Robert Moskowitz wrote:
I await the developers help.
It's not hard to do it yourself.
First, find the .spec file:
$ cd the/source/trees/root $ find . -name *.spec -print
Then see if there is a top-level 'make' rule for building RPMs:
$ grep -l spec *akefile $ less the-file-you-found-if-you-did-in-fact-find-one
Likely you'll find that you can say something like 'make rpm' to build the RPM. If not, try something like:
# cp the-spec-file.spec /usr/src/redhat/SPECS # cd /usr/src/redhat/SPECS # rpmbuild -bb the-spec-file.spec
Once you've figured out how to build the RPM, you can edit the spec file and rebuild the RPM. Right up at the top, you'll find the version number stuff. You want to change the "Release:" line. It's typically an integer, and you just increase it by 1 each time you make a new RPM with the same "Version:" line. When the version number changes, the release number gets reset to 1. A higher release number is all it takes to make rpm not complain when trying to replace an existing package with a new one with the same version number.
Warren Young wrote:
Robert Moskowitz wrote:
I await the developers help.
It's not hard to do it yourself.
First, find the .spec file:
$ cd the/source/trees/root $ find . -name *.spec -print
Then see if there is a top-level 'make' rule for building RPMs:
Arch is being used to maintain the source and I do a 'tla replay' to get the night's patches. So everything is in the tree they use. Since this is being compiled on lots of different distros, it is not following what I am used to as you indicate below.
But the developer showed me the spec file: ./test/packaging/hipl.spec, and I am playing with the Release value to include the patch level.
$ grep -l spec *akefile $ less the-file-you-found-if-you-did-in-fact-find-one
Likely you'll find that you can say something like 'make rpm' to build the RPM. If not, try something like:
# cp the-spec-file.spec /usr/src/redhat/SPECS # cd /usr/src/redhat/SPECS # rpmbuild -bb the-spec-file.spec
Once you've figured out how to build the RPM, you can edit the spec file and rebuild the RPM. Right up at the top, you'll find the version number stuff. You want to change the "Release:" line. It's typically an integer, and you just increase it by 1 each time you make a new RPM with the same "Version:" line. When the version number changes, the release number gets reset to 1. A higher release number is all it takes to make rpm not complain when trying to replace an existing package with a new one with the same version number. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
A bit of top posting.
Everything is now working as needed. At least I am making the needed changes for my own RPM building. I will get the developers to pick this up. Or at least try.
Again thanks for the help. I am almost to the point where I can find a nice public repo to place these in...
Robert Moskowitz wrote:
Warren Young wrote:
Robert Moskowitz wrote:
I await the developers help.
It's not hard to do it yourself.
First, find the .spec file:
$ cd the/source/trees/root $ find . -name *.spec -print
Then see if there is a top-level 'make' rule for building RPMs:
Arch is being used to maintain the source and I do a 'tla replay' to get the night's patches. So everything is in the tree they use. Since this is being compiled on lots of different distros, it is not following what I am used to as you indicate below.
But the developer showed me the spec file: ./test/packaging/hipl.spec, and I am playing with the Release value to include the patch level.
$ grep -l spec *akefile $ less the-file-you-found-if-you-did-in-fact-find-one
Likely you'll find that you can say something like 'make rpm' to build the RPM. If not, try something like:
# cp the-spec-file.spec /usr/src/redhat/SPECS # cd /usr/src/redhat/SPECS # rpmbuild -bb the-spec-file.spec
Once you've figured out how to build the RPM, you can edit the spec file and rebuild the RPM. Right up at the top, you'll find the version number stuff. You want to change the "Release:" line. It's typically an integer, and you just increase it by 1 each time you make a new RPM with the same "Version:" line. When the version number changes, the release number gets reset to 1. A higher release number is all it takes to make rpm not complain when trying to replace an existing package with a new one with the same version number. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
on 12-8-2008 9:13 AM Robert Moskowitz spake the following:
Ralph Angenendt wrote:
Robert Moskowitz wrote:
I have to build my own rpms for the HIPL project. I update my copy of the code and make rpm.
Thing is the rpm name never changes from patch to patch.
Is there a way to have yum apply the new code as an update and not have to erase then install?
Do it the correct way and update the spec file, so that it at least gets a new release?
For this I will have to work with the developers to find out where the spec file is and how to change it without breaking something (or get them to change it!).
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.
Those are rpm commands, not yum commands.
-
Jason Pyeron -
Les Mikesell -
Ralph Angenendt -
Robert Moskowitz -
Scott Silva -
Warren Young