[katello-devel] where to get required katello gems

[Matt Wagner]

On Mon, Jul 16, 2012 at 06:43:01PM -0400, Hugh O. Brock wrote:
<liberal snipping ensues>
> 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.

Amen to this sentiment. I think we're greatly limiting the number of
people who can use our project if we only support RPM-based distros.

> > 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).

We have various non-Ruby tools as well, which are not necessarily
terribly portable. But there's no reason that the core Ruby parts of our
app shouldn't be able to run on Debian, a Mac, or OpenBSD.

> > 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.

I'm not sure I understand this 100%. For RPM-based distros, can't we
simply keep the RPMs reasonably up-to-date? (It seems like a good part
of the process can be automated, as well.) And for non-RPM distros, we
should just use "real" gems.

Though honestly, the whole notion of packaging gems as RPMs seems weird
to me, but I guess there's precedent with other systems (e.g., CPAN). It
just feels like we're trying to encapsulate one package management
system inside another, which sounds like insanity.

> 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.

+1

> 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. 

Wouldn't it be better to just push updates to rubygems.org directly?
Forking it feels a bit like we're declaring it so broken that it's
beyond repair, and that we aren't interested in sharing our
enhancements. If we really need to have certain blessed versions, can't
we just require those exact versions, versus carrying them ourselves?

> 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.

That would be terrific! :)