[NBLUG/talk] Recompiling a RPM

[Todd Cary]

Eric -

I grasp the overall strategy in creating and using the macro, but I do 
not fully understand it's creation/syntax.  Is there a good reference to 
the syntax?

By chance, is this what the rpmdevtools is suppose to do (though I have 
only heard of it)?

Does the rpmbuild replace what is already installed?  If not, how do set 
it up so the old version is replaced?

Todd

Eric Eisenhart wrote:
> On Mon, Jan 08, 2007 at 08:58:03AM -0800, Todd Cary wrote:
>   
>> I need to recompile my version of Red Hat's PHP using the 
>> --with-interbase=shared,/opt/firebird.  I have downloaded the .src.rpm 
>> version, however I have forgotten how to recompile the src and how to 
>> replace the current version.  In fact, can that even be done?
>>
>> I cannot run RPM -e php due to the dependencies..
>>     
>
> I usually do this in a user-environment instead of as root, but here's the
> basic steps:
>
> 1) rpm -ihv blah.src.rpm
> 2) rpmbuild -ba /usr/src/redhat/SPECS/blah.spec
>
> The rpmbuild command-line can take some arguments to define things that are
> passed to the stuff in the .spec file.  Or you can modify the .spec file
> first.
>
> I highly recommend doing the following, though:
> As a non-root user:
> 1) mkdir ~/rpmbuild/ ; mkdir ~/rpmbuild/tmp ; mkdir ~/rpmbuild/RPMS
> 2) cat > ~/.rpmmacros <<EOT
> %_topdir                %(echo $HOME)/rpmbuild
> %_tmppath               %{_topdir}/tmp
> %_builddir              %{_tmppath}
>
> %_rpmtopdir             %{_topdir}/%{name}
> %_sourcedir             %{_rpmtopdir}
> %_specdir               %{_rpmtopdir}
> %_rpmdir                %{_topdir}/RPMS
> %_srcrpmdir             %{_topdir}/RPMS
> %_rpmfilename           %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
> EOT
>
> 3) as same non-root user, "rpm -ihv somepackage.src.rpm" -- it'll install
> the spec file and all its source stuff into ~/rpmbuild/packagename/.  You
> can do the same "rpmbuild" command-line stuff as a non-root user from inside
> that directory now.
>
> The biggest advantage to doing the non-root thing is that some software
> tries really hard to install itself into the system proper when you run some
> of the build/install scripts, and when you build as a non-root user that
> generates an error that you can then fix, instead of putting files on the
> system that RPM doesn't know about that will cause you trouble later.
>   

-- 
Ariste Software
2200 D Street Ext
Petaluma, CA 94952
(707) 773-4523