On Mon, Oct 4, 2010 at 9:20 AM, Todd Zullinger <[email protected]> wrote:
> Michael Stahnke wrote:
>> srpm task builds a srpm without deps so it can be built using mock
>> or some other formal build system tool.
>
> Nice. Worth noting is that without the definitions set on Fedora (and
> RHEL 6) systems or by a build tool like mock, certains conditional
> bits in the package will not be set properly during a local build. We
> could (and probably should) either guess them based on the host or
> allow them to be passed in as variables/options.
I tried this build on debian with rpm installed and no other macros or
rpm setup at all. I was able to build a srpm without issue. Of
course ?dist was not appended to release or anything like that. I
couldn't build a binary rpm on debian, due to the BuildRequires, and
debian not providing those in RPM format.
>
>> rpm builds the binary and srouce rpm locally and of course will
>> require all of the rpmbuild lity set and whatever puppet requires to
>> be built.
>
> s/srouce/source ;)
>
> I don't understand the phrase "all of the rpmbuild lity set."
It was late, and I have no idea what that was trying to say.
>
>> diff --git a/tasks/rake/rpm.rake b/tasks/rake/rpm.rake
>> new file mode 100644
>> index 0000000..c4f4fc8
>> --- /dev/null
>> +++ b/tasks/rake/rpm.rake
>> @@ -0,0 +1,80 @@
>> +PWD=`pwd`.strip!
>> +RPM_DEFINES = " --define \"_specdir #{PWD}/rpmsetup/SPECS\" --define
>> \"_rpmdir #{PWD}/rpmsetup/RPMS\" --define \"_sourcedir
>> #{PWD}/rpmsetup/SOURCES\" --define \" _srcrpmdir #{PWD}/rpmsetup/SRPMS\"
>> --define \"_builddir #{PWD}/rpmsetup/BUILD\""
>
> Would it be nicer to just use #{PWD}/rpmsetup for all these values and
> not both with seperate subdirs? For someone spitting out a single
> package, having multiple dirs seems less useful. But that might just
> be me.
>
> Ahh, I see you move them to #{PWD} later. Any reason not to just use
> that directly?
I like to build in separate sub directories in case something fails
and you want to see why, and you can still run rake clean to just
empty the whole thing. If we use PWD as the build dir, it may clutter
up the checkout on a failed build . I'm not 100% sold either way on
this point.
>
>> +
>> +def rpmbuild_setup
>> + # Ensure we're on linux and that rpm exists
>> + unless File.exists?('/usr/bin/rpm') or RUBY_PLATFORM.downcase != "linux"
>> + puts "Not an rpm based linux system"
>> + exit 1
>> + end
>> + # Ensure rpmsetup is available
>> + rpmbuil = %x{which rpmbuild}
>
> Is this intentional? Looks like it doesn't matter, since the variable
> isn't ever used. Just jumped out as odd at a glance.
I'll check that again. Intentionally, I wanted to be certain rpmbuild
was installed.
>
>> + # Remove the .sign as a required source because this is not an
>> official release with a .sign file
>
> Though it would be if building from a release tarball, wouldn't it?
> We could test whether there's a .git dir perhaps. Catching rc
> tarballs is tougher, since PUPPETVERSION doesn't contain the rcN tag
> (since gem chokes on that -- somebody please tell the gem folks to fix
> their toy packaging system please? ;)
I debated on this (not fixing gems) but the versioning of the package.
Ideally it could put an rc2, or git hash as the version if there is
nothing signed. I wasn't (and still am not) sure of all use cases for
building an rpm from the tarball/git pull.
>
>> +desc "Create a SRPM"
>> +task :srpm => :puppetpackages do
>> + sign = rpmbuild_setup
>> + if sign == 'md5'
>> + sh "rpmbuild-md5 #{RPM_DEFINES} -bs --nodeps
>> #{PWD}/rpmsetup/SPECS/puppet.spec"
>> + else
>> + sh "rpmbuild #{RPM_DEFINES} -bs --nodeps
>> #{PWD}/rpmsetup/SPECS/puppet.spec"
>> + end
>
> So sign is set to md5 only when run on EL < 6. In that case,
> rpmbuild will use the proper signing algoritm anyway. It only matters
> if you're building packages on Fedora or EL-6 that you intend to use
> on an older EL release that you have to bother with rpmbuild-md5. Or
> is that part of the grander plan, to allow specifying the target?
This was simply to ensure that if you are building an rpm, you are
certain the signing is proper. I know I often build srpms on one
platform and then submit them to mock for several versions. If you
try to put a sha-signed rpm into mock for el4 or el5, it won't work
out too well. Ideally, you'd be able to specify the target.
I'll see if I can take a look at cleaning this up in a couple ways
some time this week.
stahnma
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
