candlepin as rpm

Jesus M. Rodriguez jmrodri at gmail.com
Thu Apr 8 03:14:12 UTC 2010


On Wed, Apr 7, 2010 at 6:21 PM, Adam Young <ayoung at redhat.com> wrote:
>> How hard are the above issues to address?
>>
>> 1. is trivial will be done probably before you read this email.
>>
> Is this a debug thing?  You should be able to deploy the .war file
> directly to the server/depoly directory in JBoss.

No, it's more of an RPM thing. It allows you to own the directory that
gets exploded and when you remove the rpm it takes it with it.
It also helps in being able to create rpms that depend on the candlepin rpm
which can lay down jars in /path/to/deploy/candlepin/WEB-INF/lib/ making it
a lot easier to deploy service implementations.

>> 2. this is a bit more difficult because we need a way to update
>>     the candlepin_info.properties on the fly and the build isn't
>>     running in a git checkout at the time of the rpm build.
>>
>>     How important is the candlepin_info.properties with a git hash?
>>
>> 3. requiring rubygem-buildr is the proper way to do it, but if the
>>     rpm isn't ready for folks to deploy, then the candlepin rpm
>>     won't be buildable yet.
>>
>>     Changing it to require /usr/bin/buildr will make it buildable
>>     now and *will* require changing once we have a proper rpm of
>>     buildr.
>>
>>     An alternative is to BuildRequires: ant, add a build.xml to build
>>     the code just for the rpm. (sorry I ain't doing no  maven rpm).
>>
>>     I'm leaning towards simply requiring /usr/bin/buildr for now, and
>>     merge it into master for now with a new item to finalize the
>>     buildr rpm.
>>
>
> The Buildr RPM works now, so long as we don't need to run the cucumber
> tests.  All RPMS required are in :
> http://admiyo.fedorapeople.org/buildr/RPMS/
>
> I'll eventually get a Yum repo set up, but wget those and install should
> work for now, so long as you haven't run
> "ruby system --update"

Ok I'll update my rpms. If you want to you could just run createrepo -d
on the directory you have those RPMS in and then rsync the repo metadata
files to your people account. Unless you don't want a repo right now for
some reason.

>> 4. I think the best way is to *pass* in the version number to the
>>     build command from the spec file, and have the buildfile read
>>     the version from the spec file during dev builds.
>>
>>     In other words, in the candlepin.spec the %build section will look
>>     as follows: buildr clean test=no package version=%{version}
>>
>>     I'm not sure if this is even possible on the buildr side, but since
>>     it can do anything ruby and rake can, it's probably doable.
>>
> I'm not sure I understand the issue here.

the buildfile has a VERSION=1.0.0 which NEVER changes. And
the candlepin.spec file has a Version=1.0.1 (which is incremented by
tito during the tagging process. It would be best if we kept them
consistent. To me the buildfile should use the one passed in from
the rpm during build, and for development purposes i.e. buildr package
from your git tree it should use the git hash as the version number.


jesus



More information about the candlepin mailing list