[katello-devel] Bundler vs rpm-gems

[Hugh Brock]

On Wed, Aug 22, 2012 at 03:37:00PM +0100, Dmitri Dolguikh wrote:
> On 22/08/12 03:28 PM, Petr Chalupa wrote:
> >We already discussed solution with Gemfile.lock. There are issues.
> >
> >- You would have to have Gemfile.lock for f16, f17, el62, el63
> >- You would habe to have Gemfile.lock for production and development
> >- You will have update it every time when some version of gem or
> >rpm change in some of f16, f17, el62, el63
> 
> Hmmm. What if we bundled dependencies when we are tagging for a
> specific platform (and stripped them when packaging into rpm)?
> Troubleshooting would be quite simple then - we could even look at
> rhel issues on fedora...
> 
> -d

Could work, definitely worth looking into.

Our solution thus far has been: Upstream deployment with gem-only uses
Gemfile.lock and user-space gems. We control Gemfile.lock pretty tightly
and we really only need one version across platforms given a standard
.rvmrc that also specifies the Ruby version we use.

For RHEL deployment we move away Gemfile.lock altogether and bundler
uses system-installed RPM-based gems. I would contend that system
packaging details like this -- i.e. what RPMs are required on a
particular platform, the associated spec files, etc. -- are packaging
details that do *not* belong in the upstream project tree. This is the
standard for most upstream projects in the C world -- libvirt, for
example, does not maintain RPM specfiles for Fedora or RHEL in its
upstream tree and the standard upstream install is via ./configure;
make; make install. The RPM specs and build dependencies are tracked
separately, as are .deb packaging scripts, etc.

I'm not saying this is the only way to handle this situation but it is
the standard for many upstream projects.

Take care,
--Hugh

> >
> >It seems to me quite clumsy.
> >
> >Petr
> >
> >On 22.08.12 16:14, Lukas Zapletal wrote:
> >>On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote:
> >>>FWIW, our Gemfile.lock is in git. We don't accept changes to it without
> >>>patch review, etc. etc. Seems to work reasonably well.
> >>
> >>Our first experience was not that good, but truth is, now we do use
> >>github.com and pull requests. On the other hand, the lock file looks
> >>very messy. You guys are able to track it all?
> >>
> >>The general rule could be - no changes at all except adding new
> >>dependencies (after discussion on the list of course :-)
> >>
> >
> >_______________________________________________
> >katello-devel mailing list
> >katello-devel at redhat.com
> >https://www.redhat.com/mailman/listinfo/katello-devel
> 
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey