[katello-devel] Bundler vs rpm-gems

Thu Aug 23 12:34:50 UTC 2012

What's DSC?

LZ

On Wed, Aug 22, 2012 at 11:26:26AM -0400, Hugh Brock wrote:
> 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
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-- 
Later,

 Lukas "lzap" Zapletal
 #katello #systemengine