[katello-devel] Bundler vs rpm-gems

[Petr Chalupa]

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.

Petr

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
>