[katello-devel] Katello RPM, Ruport and Issues with Git in Gemfile

[Bryan Kearney]

On 11/14/2012 09:49 AM, Eric Helms wrote:
> On 11/14/2012 09:47 AM, Justin Sherrill wrote:
>> On 11/14/2012 09:13 AM, Bryan Kearney wrote:
>>> On 11/14/2012 09:01 AM, Eric Helms wrote:
>>>> Some background on the issue (and apologies if I get some of the
>>>> details
>>>> wrong), in order to run on Fedora 17 we need to use the gem Ruport and
>>>> specifically a bleeding edge version of Ruport 1.7.  The maintainers of
>>>> Ruport have tagged this version in their git repository but have not
>>>> pushed it out to Rubygems due to the fact that the tests need to be
>>>> fixed (David has emailed the maintainer who provided this information).
>>>> Due to this, the original inclusion of Ruport was reverted in our
>>>> codebase and then recently was un-reverted.  And after a few fixes,
>>>> works properly in development. However, attempting to build the Katello
>>>> RPM will currently break at the API generation step as it cannot find
>>>> the git checkout of the Ruport gem.
>>>>
>>>> Now, after some digging, testing and discussion, I see three options:
>>>>
>>>> 1) Figure out some way to make the bundler monkeypatch that tries to
>>>> prefer RPMs over Gems, also prefer RPMs over Git declarations of a Gem.
>>>
>>> Doesn't aeolus have this already/
>>>
>>>>
>>>> 2) Fork Ruport, name it something like "ruport-tmp" or "ruport-katello"
>>>>       Build the gem
>>>>       Push the gem to rubygems.org
>>>>       Reference this gem until the real Ruport is able to be pushed
>>>
>>> Can we push it to our own repo, and can the gemfile be layered to
>>> look there first and then to rubygems.org?
>> Yeah, assuming that we can't get the RPMs over Gems,  I think this
>> seems like the best solution.  I wouldn't use our existing gem repo
>> (maybe that should be decommissioned).   I would create a new gem repo
>> with just overrides or things missing from rubygems.org. Hopefully it
>> would remain very small.
>>
>> -Justin
>>
> +1 I think this makes the most sense.  Keeps overrides in central
> location, keeps them available to everybody and keeps us from living on
> the bleeding edge of git for gems if we ever encountered this type of
> situation in the future.

Keep the old gem repo around until the next community relase, and then 
we can kill it.

-- bk