Rpmbuild question.

[Valery Reznic]

I am also think that packaginf from the buildroot is important thing.
Otherwise you can miss a lot of different problem during testing.

Nevertheless, what about this worjaround:

1. Create symlink from / to /some/place
2. Use /some/place as builldroot

Valery.




>________________________________
> From: Tim Mooney <Tim.Mooney at ndsu.edu>
>To: General discussion about the RPM package manager <rpm-list at lists.rpm.org> 
>Sent: Saturday, May 5, 2012 12:29 AM
>Subject: RE: Rpmbuild question.
> 
>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 at ndsu.edu
>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 at lists.rpm.org
>http://lists.rpm.org/mailman/listinfo/rpm-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20120505/9117817e/attachment.html>