[katello-devel] Bundler vs rpm-gems

[Hugh Brock]

On Wed, Aug 22, 2012 at 05:02:18PM +0200, Petr Chalupa wrote:
> For RHEL deployment we move away Gemfile.lock altogether, this will
> work. But you do not have a way how to install rest of the
> development dependencies on RHEL, keep the older rpm-gems and
> install corecct versions of development gems.

Hmm... well, OK, I think we need to get precise about exactly what the
goal is here. 

Should you want to develop on RHEL -- fix bugs, do new work, whatever --
I believe the best way to do that going forward is going to be via a
DSC. In other words, forget the native RHEL stack altogether since it
will be of no help. We don't currently have a blessed DSC for Cloudforms
on RHEL but I believe we need to get there ASAP. Given a suitable RHEL
production DSC and a parallel development DSC, you can develop nicely on
an RPM-based system without having to worry so much about getting
packages into RHEL proper.

Should you want to develop on Fedora or another non-production platform,
use gems, and ideally the packaged versions of your dependencies for
that platform. I would like to have a DSC that would work on fedora as
well, since I don't believe the native Fedora ruby platform offers much
more value than the antiquated one in RHEL.

Happy to hear what's wrong with this, but just keep in mind that we want
to keep packaging overhead to an absolute minimum.

--Hugh

> 
> On 22.08.12 16:46, Hugh Brock wrote:
> >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
> >
> 
> _______________________________________________
> 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