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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20081208/6ff3fa1b/attachment-0003.sig>
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 at centos.org > [mailto:centos-bounces at 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 at 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.
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.rpmoh. 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!
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.
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 at 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 at centos.org >> http://lists.centos.org/mailman/listinfo/centos >> >> >> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > >