[katello-devel] Bundler vs rpm-gems
Hugh Brock
hbrock at redhat.com
Thu Aug 23 13:07:00 UTC 2012
On Thu, Aug 23, 2012 at 02:59:06PM +0200, Vít Ondruch wrote:
> https://fedorahosted.org/SoftwareCollections/
>
>
>
> Dne 23.8.2012 14:34, Lukas Zapletal napsal(a):
> >What's DSC?
> >
Yes. And I've just realized that Openshift have an up-to-date DSC that
includes Rails 3.2, Passenger (I think), Ruby 1.9.3, etc. I'd like to see Aeolus and
Katello move to that as soon as possible after 1.1 goes out.
--H
> >
> >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
>
> _______________________________________________
> 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
More information about the katello-devel
mailing list