[katello-devel] where to get required katello gems

[Bryan Kearney]

On 07/16/2012 06:43 PM, Hugh O. Brock wrote:
> On Mon, Jul 16, 2012 at 05:57:04PM +0200, Petr Chalupa wrote:
>> I am the osx user so I have to speak out ;)
>>
>> I think this is not just my issue. Not everybody is running on
>> fedora, this affects all debian-based distributions as well. I think
>> it should be solved satisfactory not to discourage potential
>> contributors.
>>
>> I think they like theirs tweaked machines, they are used to theirs
>> tools and They want to use them as I do. To do so you need run
>> katello app locally against a VM with services (db, pulp,
>> candlepin).
>>
>> I may have a compromise:
>> - If all gems are in rpm repos, with the .gem files actualized.
>> - Then a developer can do 'bundle package' on the VM to get
>> vendor/cache with all needed gems including theirs CVE patches.
>> - Then he can run 'bundle install --locally' on any development
>> machine and he is good to go.
>>
>> We can later decide to add a repo with vendor/cache to make it even easier.
>>
>> To sumarize: I think the main issue for non fedora development
>> machines are not updated .gem files in rubygem rpms.
>>
>> Petr
>
> I've made the mistake before of trying to dictate what happens
> upstream to the upstream team, so I'm not going to do that this
> time. :).
>
> However, my view, and the view of most of the folks I've talked to on
> the Aeolus team, is that RPM packaging and installing from RPM or
> using any other distro tools is an unnatural act for a ruby
> developer and that it is (one of the many things) impeding our
> progress with building an upstream community.
>
> Now, it goes without saying that we will need to package our upstreams
> as RPMs in order to productize. However my personal opinion is that it
> will be better for our upstream community health, and development
> time, if we can stop the packaging tail from wagging the software dog
> and let the upstream be a pure Ruby project.
>
> One way we could minimize the inevitable package proliferation pain
> we'll incur by doing this is by pitching in to maintain a shared gem
> repo across projects. I had even thought about a rubygems.org fork
> that would provide a bit more of a gate than straight upstream, I
> don't know what others would think of this. It sounds like Petr has
> suggested something similar above, but I would skip the RPM step
> even.


Could we use a pulp instance to handle gems, and have it mirror the 
rubygems url?


>
> Anyway, obviously Katello upstream is free to do what it wants, but I
> believe Aeolus is going to move away from knee-jerk RPM packaging and
> instead plan to package our upstream releases as tarball + gems +
> Gemfile, as you would expect a Ruby project to do.

What about the backend engines, Image Factory et al?

- bk