In regard to: RE: Rpmbuild question., Wempa, Kristofer said (at 7:59pm on...:
Setting the %buildroot to %{nil} doesn't work. Rpmbuild fails with an
error that buildroot can't be empty. We don't build our tool chains as
root and we install everything into a dedicated directory that we own.
So, there is little benefit to using a build root and it further
complicates our tool chain build process. If I can't unset the
%buildroot variable, then it seems for me that the easiest solution is
to just copy the files into the build root directory after they are
installed. I have hundreds of SPEC files that I'll need to change, but
I should be able to automate those changes with a script. I appreciate
you explaining the history behind the change, but I still think there
should be a means to get it to behave the old way. I think NOT building
as root is way more important than using a build root.
I'm sorry to hear that setting %buildroot to %{nil} didn't work, and I
hope you don't think I'm trying to be a jerk for proselytizing the
buildroot -- most people say I don't need to *try* to be a jerk, it's just
natural for me. ;-)
I totally agree that *not* building as root is more important than
a buildroot. I guess I've just been spoiled in that the developers I've
worked with have always been forced to using a development model that
mirrors how a lot of open source packages work. In that model, prepping,
building, and installing (into a build root) using the rpm model mostly
come naturally.
I also agree that your path of least resistance at this point is going
to be to copy the files into the buildroot as part of the %install.
Hopefully my other response in this thread helps with that too.
Regarding that "...So, there is little benefit to using a build root"
comment, I think I actually disagree, for reasons I alluded to in my
other response in this thread. If you're going to provide RPMs to
customers (whether internal or external), why not "eat your own dogfood",
so to speak? Make it such that the files that get installed in
/opt/yourcompany or wherever *only* get put there as the result of
installing an RPM? That way you're not using one thing internally and
providing customers something else. If you do testing after installation,
then you're testing the actual files that come from the RPM.
As an example, if you allow your build system to just plop files into
their final location, rather than using a buildroot, let's say that your
software depends on /opt/yourcompany/etc/yoursoft.conf, but someone
forgets to package it in the RPM. This can easily happen, especially
when new files and requirements are added.
If you don't use a build root, then your testing likely will not uncover the
fact that the RPM you provide to customers is missing something. You
don't notice it because it *isn't* missing on your system; it was
deposited there by your build process. If you had used a buildroot and
mandated that your build process didn't put anything into the final
destination tree, you would have turned that up when you installed the
package (via rpm -Uvh) and discovered that a config file was missing.
This is just the most common example, but there are other similar
scenarios that can happen when you use RPM as a scoop-and-bundle
mechanism from a set of directories that contain files of unknown
provenance.
Hopefully the transition to using a buildroot doesn't turn out to be too
painful,
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
