[Crowbar] Can I have Gemfile.lock back?

Adam Spiers aspiers at suse.com
Thu Jan 3 07:58:54 CST 2013

Ralf Haferkamp (rhafer at suse.de) wrote:
> On Thu, Dec 20, 2012 at 03:36:08PM +0000, Adam Spiers wrote:
> > Ralf Haferkamp (rhafer at suse.de) wrote:
> > > On Thu, Dec 20, 2012 at 02:51:50PM +0100, Ralf Haferkamp wrote:
> > > > On Thu, Dec 20, 2012 at 01:40:47PM +0000, Adam Spiers wrote:
> > > > > Adam Spiers (aspiers at suse.com) wrote:
> > > > > > So I'm now thinking b) might be better, and in SUSE we can just do
> > > > > > bundle install --local at package build-time to generate Gemfile.lock.
> > > > > > Then if our gem rpms don't provide versions which satisfy Gemfile's
> > > > > > requirements, the crowbar-barclamp-crowbar package will fail to build,
> > > > > > which is good.
> > > > > 
> > > > > Hmm, the downside of running bundle install --local at packaging-time
> > > > > is that it would require a BuildRequires in the .spec to ensure that
> > > > > each required gem is already in the local cache.  Writing those
> > > > > manually is a pain, but they can only be generated from a
> > > > > Gemfile.lock, which would require running bundle install --local,
> > > > > which requires ... chicken and egg :-/
> > > >
> > > > Why not create the BuildRequires from the Gemfile? The information in there
> > > > should be enough, right?
> > 
> > Actually yes, that should be right.
> > 
> > > Generating the correct runtime dependencies for the RPM might be a little
> > > harder.
> > 
> > I think I got confused before

Err ... no I didn't, I got confused when thinking about what I
previously wrote %-/

> > I should have been talking about
> > runtime dependencies not BuildRequires.  Are there gems which are
> > really needed at build-time? (except maybe bundler for creating
> > Gemfile.lock)
> No.

In one sense you are right :-)  But the gems *would* be needed at
build-time if we wanted to generate Gemfile.lock then via "bundle
install --local", since this requires the gems satisfying the
constraints in Gemfile to be in the local cache.  So if we decide to
generate Gemfile.lock at rpm build-time, then all run-time gem
dependencies end up being build-time dependencies too.

Let's go back to Ralf's original question.  Gemfile.lock was removed
from the barclamp-crowbar git repo, but we need it *somewhere* for two

  1. Without it, the Crowbar Rails app won't start :-)

  2. To ensure we have the right versions of all the required
     gems, i.e. that the constraints in Gemfile are satisfied.

If we provide the gem dependencies as rpms, then generating
Gemfile.lock ourselves via "bundle install --local" will cross-check
Gemfile against the locally installed gem rpms.  The question then
arises: do we do this in the %install phase of the
crowbar-barclamp-crowbar.spec rather than its %post phase?

  - If %install, the Gemfile constraint checks happens in the Build
    Service; if %post, they happen during application testing.

  - If %install, rpm -V crowbar-barclamp-crowbar will spot a corrupt
    Gemfile.lock.  If %post, there is no hard guarantee that
    Gemfile.lock will be the same across multiple installs (although
    with a fixed set of gem rpms, I can't think how it would differ).

Personally I think it feels more "right" to do at build-time in
%install, but it's probably more effort to implement.  We could work
around the chicken-and-egg problem I previously mentioned by extending
rubygemsdeps.rb from ruby-common:


so that it can consume a Gemfile as input (currently it can only
process a .gem or .gemspec file).  

This would allow us to manually trigger automatic updates of a list of
BuildRequires hardcoded in crowbar-barclamp-crowbar.spec and delimited
by "# BEGIN automatic BuildRequires" / "# END automatic BuildRequires"
lines, in a similar manner to how the "all-good" meta-package in the
systemsmanagement:crowbar:2.0 is currently generated:


Alternatively we could ditch the last 3 months of gem packaging work
and just take the SUSE Studio / HAWK approach of having a single rpm
which contains all required gems via "bundle package" ... :-/

More information about the Crowbar mailing list