[katello-devel] Bundler vs rpm-gems

Thu Aug 23 12:59:06 UTC 2012

https://fedorahosted.org/SoftwareCollections/


Dne 23.8.2012 14:34, Lukas Zapletal napsal(a):
> 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