-----Original Message----- > From: rpm-list-bounces@xxxxxxxxxxxxx [mailto:rpm-list-bounces@xxxxxxxxxxxxx] On Behalf Of Tim Mooney > Sent: Friday, May 04, 2012 5:29 PM > To: General discussion about the RPM package manager > Subject: RE: Rpmbuild question. > 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. ;-) > Not at all. I totally support preaching best practices. As far as "build roots being encouraged for many years", I wasn't active on any of the RPM mailing lists and only started using RPM back in 2008. What little RPM documentation I found merely suggested that you *could* use a build root and listed the reasons why you might want to do that. I certainly never came across anything that emphasized it or even suggested that you might be forced to use one at some point. Up until now, such major changes to software packages that I've encountered have always been done with an option to "do things the old way". > 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. > This seems to be working OK, although it requires changes to all of the spec files. Further complicating things is that we create RPMs for Perl/Python/Ruby/R modules, which require different logic to determine the set of package files. So, those spec files require their own specialized changes to support this. Since there are so many spec files, I have to write a custom script to make these changes. > 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. > We already handle such situations. We have 2 separate environments: a staging environment and a production environment. Our tool chains are built and installed into their own directory. That directory is mounted from a different disk on the production machines. So, we create the RPMs in the staging environment as a non-root user and then install them in the production environment for testing. Any cases such as you mentioned will be detected during testing. ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
