[katello-devel] Bundle install problems should be gone now

[Jeff Weiss]

On Tue, 2011-08-09 at 09:37 +0200, Lukas Zapletal wrote:
> On 08/09/2011 01:33 AM, Mike McCune wrote:
> > good progress but did you test this?
> >
> > I tried a fresh install on F14 and F15 and neither work out of the box:
> 
> Mike,
> 
> I did test it, but I forgot to completely uninstall all the rubygems 
> (yum remove ruby step).
> 
> The build you were trying was build against a different rubygem-rack RPM 
> then you are downloading from our repo.
> 
> This shows one thing - our build & packaging environment is not much 
> stable. It confirms my & Shannon's words we should accelerate process of 
> getting Katello to the Brew.

I'm curious what features Brew offers to make this pain easier?  I don't
know much about Brew, but apparently it runs Koji, and the Koji doc page
says 
https://fedorahosted.org/koji/

"Uses Yum and Mock open-source components"

That's exactly what our builds (on Jenkins at least) already use.  So
while I am not trying to dissuade anyone from using brew, I don't see
how it's going to help solve this particular problem.  Maybe someone can
fill me in.

Jeff



> There is a rich ongoing discussion on the ruby-sig mailing list about 
> options to solve this. I just gathered all the recommendations in this mail:
> 
> http://bit.ly/qfe3wZ
> 
> What Mo Morsi recommends is pretty similar what I did, but he would 
> rather generate patches for the Gemfile.lock for the every possible 
> Fedora version we will support. We won't need to issue "bundle install" 
> in the SPEC, but the process will be more difficult as we would need to 
> really pay attention when changing the Gemfile.lock in our git, keep all 
> the Gemfile.lock patches in our git, have some automated checker job to 
> test installs and to send diffs when versions goes wrong.
> 
> Having a stable build environment is a must for this approach as well. 
> This does not change a thing.
> 
> I would recommend to go for the quick&dirty solution for now (until we 
> get stabilized and get to the Fedora) - to regenerate Gemfile.lock 
> before each start. It won't hurt much we are building against wrong 
> versions of rubygems for some time then. And when we get there, we could 
> re-visit this and probably go for the lockfile patches.
>