rpm-list-bounces@xxxxxxxxxxxxx wrote on 06/15/2009 06:58:41 PM:
> Sorry if this is a FAQ... I didn't find the answer by googling yet,
anyway.
>
> At my job (working on an embedded system), we are hosting the RPM
> directory (the whole tree that would normally be at /usr/src/rpm) in
> ClearCase. That way we get version control of SPEC files. But, for
> in-house maintained stuff (like say a collection of scripts that goes
> into an RPM), it's not convenient to have to make a tarball. I check
> in the tarball, but to see diffs from one version to the next, you'd
> have to check out both versions, untar them, and do a diff. Is there
> a way for a spec file to specify that the source comes from a
> directory instead? Then we could version-control each file that goes
> into the RPM rather than having to check in the whole tarball. For
> example I could just check in the BUILD directory (and all
> subdirectories and files) instead, and have rpmbuild skip the
> untarring step, assuming that the tar has already been extracted
> there.
I sympathize with your problem. We used to have various custom inhouse
scripts that dealt with this so that we didn't have to make a tarball.
Then I was playing with func one day and noticed that they use a Makefile
to do their build activities. I doubt they were the first, but its a great
idea none the less. I'm attaching a sample of a Makefile I use as a base
template for our non-python projects. Basically you have your directory
that contains all of your source, in its untar'd form as well as the spec
and Makefile. The Makefile has a function called "sdist" (i used the
python setup-tools naming because thats where I started using the
Makefiles). It has another function called "rpms" that references the
"sdist" function. In general I've made this attached Makefile so general
that you can drop it in the source directory and type "make" and you will
get your rpm. (Although your spec probably has Source0:
%{name}-%{version}.tar, which will now need to be just %{name}.tar) If
there are more than 1 spec files in the directory, you need to adjust, but
otherwise it works great.
Lately I've taken it a bit further and added the "make publish" option,
which I haven't found a way to make very general, but My build process is
down to:
make
make publish
its nice, and Makefiles are a pretty well known process for other
activities so the internal support cost is much lower since its not a
completely custom build system.
-greg(See attached file: Makefile)Attachment:
Makefile
Description: Binary data
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
