[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-list
Subject:    possible to build an RPM from source directory rather than  tarball?
From:       shawn.t.rutledge () gmail ! com (Shawn Rutledge)
Date:       2009-07-14 21:06:26
Message-ID: d9a6586e0907141406gf2ce60m58d5e5c9f25c7665 () mail ! gmail ! com
[Download RAW message or body]

Thanks Tim and Greg for the Makefile idea; I have it working
reasonably well now.

One thing I ran into is that it seems the source tarball's top
directory must be of the form package-version, e.g. foo-1.2.3.  Which
raises the need to extract the version from the SPEC file, and then
"stage" the files into a directory named that way so as to be able to
create the tarball.  But I guess you avoided needing to do that?
Maybe it depends which version of rpm, whether that's a requirement or
not...

So it looks like this now:

PACKAGE := $(shell basename *.spec .spec)
RPMVERSION ?= $(shell grep ^Version *.spec | cut -d' ' -f2)
RPMRELEASE ?= $(shell grep ^Release *.spec | cut -d' ' -f2)
PACKAGE_VERSION := $(PACKAGE)-$(RPMVERSION)

sdist: rpmclean
	mkdir -p tarstage
	mkdir -p tarstage/${PACKAGE_VERSION}
	cp -a stage/* tarstage/${PACKAGE_VERSION}
	tar -cf ${PACKAGE}.tar -C tarstage ${PACKAGE_VERSION}

... etc

with the assumption that the stage directory already has the final
filesystem layout (e.g. having done a make install into there, or just
checking in the files in the correct layout under stage).  Files are
copied from stage to tarstage/foo-1.2.3/ and the tarball is created
from there.  But then rpm does its own staging again into the rpmbuild
directory, so ugh... how redundant.

I was working on a way to use dialog to prompt for the version and
release numbers (with the default taken from the highest numbered RPM
that already existed, so you typically just backspace and increment
it), but rpm always uses the numbers from the spec file, right?  If
there was a way to override it from the rpmbuild parameters, that
would be nice, then I wouldn't have to modify the spec file every time
there is a minor bugfix.  Of course the spec file could be
programmatically modified too...

[prev in list] [next in list] [prev in thread] [next in thread]