[PATCH] Added 'make rpm'
Shawn Wells
shawn at redhat.com
Mon Apr 2 21:00:17 UTC 2012
On 4/2/12 2:58 PM, Spencer R. Shimko wrote:
> On 4/2/12 2:27 PM, "Shawn Wells"<shawn at redhat.com> wrote:
>
>> >
>> > On 4/2/12 1:52 PM, Spencer R. Shimko wrote:
>> >
>> > On 4/2/12 1:31 PM, "Shawn Wells"<shawn at redhat.com>
>> ><mailto:shawn at redhat.com> wrote:
>> >
>> >
>> > > >+rpm: dist
>>> >>+
>>> >>+ # A few quick notes on preparing your system to build the SSG RPMs:
>>> >>+ # (1) May the flies of a thousand horses annoy you for eternity
>>> >>+ # if you build an RPM as root. Don't do it!
>>> >>+ # (2) This build process assumes you have your rpmbuild structure
>>> >>setup
>>> >>+ # $ sudo yum -y install rpm-build
>>> >>+ # $ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
>>> >>+ # (3) The value if ${DIST} in this Makefile needs to match
>>> >>+ # the %{name}-%{version} string from the .spec file, i.e.
>>> >>+ # scap-security-guide-alpha
>>> >>+ # (4) If you're making an RPM, chances are the code has changed.
>>> >>Make
>>> >>+ # sure you update the %changelog in the .spec to reflect what's
>>> >>new
>>> >>+
>>> >>+ # copy template .spec over to rpmbuild
>>> >>+ cp ${IN}/rpmbuild/scap-security-guide-alpha.spec ${OUT}/
>>> >>+
>>> >>+ # tar up the sources
>>> >>+ tar -zcvf ${OUT}/scap-security-guide-alpha.tar.gz ${DIST}
>>> >>+ mv ${OUT}/scap-security-guide-alpha.tar.gz ~/rpmbuild/SOURCES/>+
>>> >>+ # let's see if a build works
>>> >>+ rpmbuild -ba ${OUT}/scap-security-guide-alpha.spec
>>> >>+
>>> >>+ # Our RPM(s) will be waiting for us in ${HOMEDIR}, so copy them back
>>> >>+ mv ~/rpmbuild/RPMS/ ${OUT}/
>>> >>+
>>> >>+
>> >
>> >
>> >
>> > I'm not happy with assumptions regarding user environment. We
>> >don't
>> >control rpmbuild or the RPM macros file. Barring those issues this also
>> >makes some assumptions about directory structure that might not be
>> >correct.
>> >
>> >
>> >
>> >
>> > All valid. I wanted to get*something* in there that would work on a
>> > stock RHEL6 build system.
>> >
>> > What I'd*really* like to see is input/rpmbuild be setup as a
>> > localized buildroot which would allow us to be completely self
>> > contained (and much more elegant). But I have no idea how to do that
>> > and in mucking around it didn't become apparent to me. Hopefully
>> > someone with more RPM knowledge than me could patch to make that
>> > happen.
> How about supporting both mock and plain RPM builds? We have a build
> system that does that internally that we can apply to this situation (we
> are done with the fragility of build VMs). But the caveat here is that it
> comes with some rather significant complexity. Not auto make's level of
> complexity, but perhaps unnecessary complexity for this project.
>
> A simpler approach that just handles RPM builds (no mock) can be found
> here:
> http://oss.tresys.com/projects/clip/browser/trunk/refpolicy/build/Makefile
Read through your Makefile.... very clean. I've got no objections on
using mock, especially to create the SRPMs. And IMO there shouldn't be
much of a problem introducing complexity if it creates cleaner output
than we're otherwise capable of producing.
Are you volunteering to clean up the Makefile, or should I take a stab
at it?
###
> <snip>
>>> >>+%install
>>> >>+rm -rf $RPM_BUILD_ROOT
>>> >>+#make install DESTDIR=$RPM_BUILD_ROOT
>>> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/content
>>> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/guide
>>> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/policytables
>>> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/STIG-draft
>>> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/USGCB-submission
>> >
>> >
>> >
>> > How does this work if $RPM_BUILD_ROOT has spaces?
>> >
>> >
>> >
>> >
>> > Assumed stock environment. Patches welcome.
> Cool. FWIW the link I pasted above has the same issue. I'll fix it up in
> SSG and push a patch soonish.
>
>> >
>> > >+
>>> >>+cp -r * $RPM_BUILD_ROOT/usr/local/%{name}/
>>> >>+
>>> >>+
>>> >>+%clean
>>> >>+rm -rf $RPM_BUILD_ROOT
>>> >>+
>>> >>+
>>> >>+%files
>>> >>+%defattr(-,root,root,-)
>>> >>+%doc
>>> >>+
>>> >>+%attr(0750,root,root)/usr/local/scap-security-guide/>+
>>> >>+%changelog
>>> >>+* Mon Apr 02 2012 Shawn Wells<shawn at redhat.com>
>>> >><mailto:shawn at redhat.com>><mailto:shawn at redhat.com>
>>> >><mailto:shawn at redhat.com> 1.0-1
>>> >>+- First attempt at SSG RPM. May ${diety} help us...
>>> >>diff --git a/rhel6/src/output/.gitignore b/rhel6/src/output/.gitignore
>>> >>index 7206c02..4bbeae5 100644
>>> >>--- a/rhel6/src/output/.gitignore
>>> >>+++ b/rhel6/src/output/.gitignore
>>> >>@@ -3,3 +3,8 @@
>>> >> *.html
>>> >> *.pdf
>>> >> *.ini
>>> >>+*.spec
>>> >>+*.tar
>>> >>+*.gz
>>> >>+scap-security-guide-*/
>>> >>+RPMS/
>>> >>--
>>> >>1.7.1
>>>>> >>>>
>>> >>
>>>> >>>
>>> >>
>>> >> Pushed
>> >
>> >
>> >
>> > I'd prefer to wait for at least one ACK before pushing. IMO an
>> >ACK from
>> >anyone with commit access should be sufficient for a merge/push.
>> >Thoughts?
>> >
>> >
>> >
>> >
>> >
>> > Personally I'd like to see*every* patch hit the mailing list and
>> > get 1-2 ack's, but it's been the wild west as we get core content
>> > created. While I want it now, I'm thinking that once alpha drops all
>> > patches need to be sent out before commits.
> Sounds good to me.
--
Shawn Wells
Technical Director,
U.S. Intelligence Programs
(e) shawn at redhat.com
(c) 443.534.0130
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://fedorahosted.org/pipermail/scap-security-guide/attachments/20120402/3390cfbc/attachment-0001.html>
More information about the scap-security-guide
mailing list