Creating RPMS from source without Makefile

Steve Phillips steve at
Tue Oct 16 07:19:54 UTC 2007

Mertens, Bram wrote:
>> From: redhat-list-bounces at 
>> [mailto:redhat-list-bounces at] On Behalf Of Michael Schwendt
>> Sent: dinsdag 16 oktober 2007 0:57
>> To: General Red Hat Linux discussion list
>> Subject: Re: Creating RPMS from source without Makefile
>> On 15/10/2007, Mertens, Bram <mertensb at> wrote:
>>> Hi,
>>> For several applications/tools I'd like to create an RPM to make
>>> maintenance easier.  However some of these come without a Makefile
>>> (usually just untar in the correct directory).  For others 
>> I'd like to
>>> add some additional (configuration) files and such.
>>> According to the maximum rpm book it is recommended to keep 
>> patches and
>>> such separate from the original sources (pristine sources). 
>>  But so far
>>> I've been unable to find an explanation on how exactly to 
>> set this up.
>>> I've download the httpd source rpm and noticed that it contains some
>>> additional files in the SOURCES directory which have been added as
>>> additional "SourceX" lines in the spec file.  These are installed by
>>> additional "install" commands in the spec file.
>>> Is this the recommended approach?  Is there a way to group 
>> these files
>>> somehow?  After installing the httpd source rpm the SOURCE dir was
>>> filled with files with no way to determin which were related to the
>>> httpd package wand which not.
>> That is only due to your particular [default] RPM setup, where all
>> SourceX files are stored in the same directory. However, it is not
>> like that when you customise RPM in your $HOME/.rpmmacros file. For
>> example, you can override the default locations like this
>> %_topdir     %(echo $HOME)/rpm
>> %_sourcedir     %{_topdir}/SOURCES/%{name}-%{version}
>> %_specdir       %{_sourcedir}
>> and get a separate directory for each package/version. A very few
>> packages may break since they make poor assumptions about your RPM
>> build tree.
>> Of course, you can also tar your set of patches and additional source
>> files, put it into a single SourceX tag, untar it in %setup and access
>> the files via $RPM_BUILD_DIR. It is much less convenient, though.
> Thanks I'll look into organizing my files this way.  However I believe
> it doesn't solve the problem of installing source rpms like the httpd
> package.  Or will rpm -I package.src.rpm create/use these directories if
> I create an rpmmacros file for root?

if you 'rpm -i' the src rpm package you will find that it basically 
'unzips' to /usr/src/redhat/SOURCES directory, and the 'source' tends to 
be a tarball (the pristine source) and next to it you should find a 
bunch of patch files/diffs/etc

there should also be a spec file that details just how the package is 
built - this will be similar to a script that contains commands such as 
how to untar the 'pristine source' and apply the patches to the source 
in order to create a build for your environment - a lot of the time this 
will allow you to build with additional tags - like, say -nogui if you 
didnt want to build a gui part of the rpm, of course, these flags will 
depend entirely on your spec file and how the author of the rpm decided 
to arrange things.

the spec files generally unzip (for want of a better word for the rpm -i 
of a source rpm) into /usr/src/redhat/SPECS

Usually building 'from a tarball' will require a spec file buried 
somewhere within the tarball that tells rpmbuild how to build the 
binaries from source, but in this case you wouldn't have a .rpm file to 

Spec files can be quite complex in some instances, and in others, they 
can be quite simple, I'd probably try taking a look at one from a simple 
package first - try something like netcat (this is a wild guess, but I 
believe the build for that was quite simple)

no makefiles needed :-) (well, obviously, within the package itself 
probably, but the spec file takes its place for your purposes and lives 
in the SPECS directory)


Steve  |()  ascii ribbon campaign - against html e-mail
        |/\   - against proprietary attachments

More information about the redhat-list mailing list