In regard to: Re: Rpmbuild question., Jim Lynch said (at 3:39pm on May 4, 2012):
On 05/04/2012 11:32 AM, Jim Lynch wrote:
I am attempting to generate an .rpm file from a spec file that works OK on
cents 4 and 5. But fails miserably on 6.
...
Thanks for all the advice. I understand what's happening but it's a
real pain to work around it. I'm obviously going to have to add
additional steps into my processes.
As is pretty obvious, I install to /usr/local/bin et al. Then
test. If all is well then do the build.
I'm assuming it's pretty complicated to perform your tests in the build tree,
before any "install" target is executed, so the testing must be done when
the files are all in their final destination. With that in mind, the best
suggestion I can offer is
- always do the rpmbuild, even if it's for a version you're only
considering a test. Use the buildroot when packaging your software.
- actually install the software (rpm -Uvh yourpackage.rpm) so that its
bits end up in the final destination, and *then* do your testing.
- if the test works, you can release your package knowing that *nothing*
has changed between the version you tested and the files you packaged.
You tested the actual packaged version that you're releasing to
customers (internal or external).
- if tests turn up problems, bump version number in some fashion, and
repeat.
The problem with this is that it can lead to "version inflation", but
there are things you can do to avoid that. I don't know if your package
uses "semantic versioning" (www.semver.org), but with just a little bit
of macro usage you could make it such that you can easily (from the
command line) tag certain builds as "snapshot" builds, so they don't
contribute to a constant version inflation.
Now I'm going to have to install to
/usr/local/bin test and copy to a build directory then build, or install to
the build directory, copy to the system directory, test and then build or
install to the build directory, build, install from the rpm and test (Ugh).
It sounds to me like there's one thing happening here that I must have
missed earlier; your %prep and %build aren't actually controlling the
preparation or the building of the software. Am I right that you're doing
that externally, and your spec file(s) are really only getting involved in
either the %install or (more likely) just the %files section?
If that's the case, it does indeed complicate things, however, there's
always a way. Although I am definitely *not* advocating this, there's
nothing to say that your specs couldn't be modified so that you have
%prep
# our external system has already prepared, built and installed the
# software into what its final location will be. Now we scoop it
# up with RPM for packaging.
# make certain the necessary directories exist under RPM's build root:
for d in /usr/local/bin /etc/cron.d /etc/whatever/else
do
test -d $RPM_BUILD_ROOT$d || %__mkdir_p $RPM_BUILD_ROOT$d
done
%build
# Nothing to build, our external system built & installed the
# software already
exit 0
%install
# Transfer (copy) the binaries that our external system built & installed
# into the buildroot that RPM uses for packaging
for f in /usr/local/bin/program1 /etc/cron.d/cron-file \
/etc/whatever/else
do
cp -p $f $RPM_BUILD_ROOT$f
done
Although I think your build/install/test process would benefit from
letting RPM control more of the phases, doing something like what I show
above allows it to work with what you have.
I have a number of different applications all interconnected and somewhat
dependent.
:-) RPM is great with interdependencies. ;-)
I attempted to put everything in a single directory tree, but
rpmbuild doesn't like that. If I accept the default tree structure then each
time I change version/revision I'll be starting a new tree branch and have to
come up with some way to weed out the old branches.
I'm not really following that, but that's OK.
I hope some of this helps you adjust to the forced buildroot.
Tim
--
Tim Mooney Tim.Mooney@xxxxxxxx
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
