[katello-devel] where to get required katello gems
Hugh O. Brock
hbrock at redhat.com
Mon Jul 16 22:43:01 UTC 2012
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.
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.
Take care,
--Hugh
>
> On 16.07.12 16:23, Lukas Zapletal wrote:
> >The issue is not about how to work with bundler. If we package all the
> >build deps as RPMs, we dont need bundler anymore. So installing
> >development setup would be just like installing one metapackage via yum.
> >That's it. And we are not far from that!
> >
> >Rubygems in Red Hat's world are evil. Just like JAR files. Our customer
> >do deliver using RPMs. We should do the same. I can understand it is
> >very comfortable to have ability to run rvm or bunlder, but this is
> >fight that every developer must do its own. Especially those with MacOS
> >;-)
> >
> >My point is - instead of providing rubygem repos or fighting with
> >bundler configurations, let's just package devel only dependencies as
> >RPMs so devs can install them just like any other software they use. And
> >then handle bunlder the usual way (deleting lock file, generating lock
> >file in RPM post trans script, every team has its own way).
> >
> >Bundler is something we don't need. Actually, it's an obstacle we should
> >rather get rid of. JBoss folks could tell stories (Maven)...
> >
> >LZ
> >
> >On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote:
> >>
> >>
> >>----- Original Message -----
> >>>
> >>>
> >>>----- Original Message -----
> >>>>From: "Bryan Kearney" <bkearney at redhat.com>
> >>>>To: katello-devel at redhat.com
> >>>>Sent: Monday, July 16, 2012 8:23:25 AM
> >>>>Subject: Re: [katello-devel] where to get required katello gems
> >>>>
> >>>>On 07/16/2012 07:26 AM, Petr Chalupa wrote:
> >>>>>I have a counter proposal which is more from Ruby world then the
> >>>>>solution described in previous emails.
> >>>>>
> >>>>>- remove source
> >>>>>'http://repos.fedorapeople.org/repos/katello/gems/'
> >>>>>and
> >>>>>other sources from Gemfile
> >>>>>- store all needed gems in vendor/cache as .gem files (directly
> >>>>>in
> >>>>>katello master or a git-submodule) (all versions for f16 and
> >>>>>RHEL)
> >>>>>- install gems with bundle install (without source specified
> >>>>>bundler
> >>>>>picks up gems from vendor/cache)
> >>>>>
> >>>>>Advantages:
> >>>>>- you can install all required gems on any platform: fedora,
> >>>>>ubuntu
> >>>>>or
> >>>>>osx (which I need)
> >>>>>- faster installation
> >>>>>- you can switch between fedora/RHEL env by replacing
> >>>>>Gemfile.lock
> >>>>>(lets
> >>>>>say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our
> >>>>>git
> >>>>>for
> >>>>>this purpose)
> >>>>>- easy access to and updates of gem versions
> >>>>>- you can include gems with CVE patches from fedora, everybody
> >>>>>would
> >>>>>have correct versions of gems (which I currently don't have)
> >>>>>
> >>>>>Disadvantages
> >>>>>- rubygem-* rpms are not being correctly packed. The included
> >>>>>.gem
> >>>>>files
> >>>>>are not containing CVE patches. We would need to come up with a
> >>>>>workaround to build updated .gem files or fix the issue. If this
> >>>>>is
> >>>>>fixed, all you have to do to store gems in vendor/cache is
> >>>>>'bundle
> >>>>>package' [1].
> >>>>>- other possible problems i do not see, any ideas?
> >>>>>
> >>>>>[1] http://gembundler.com/bundle_package.html
> >>>>>
> >>>>>What do you think?
> >>>>>
> >>>>>Petr
> >>>>>
> >>>>
> >>>>Could we do this model for DEV, and then work on proper packaging
> >>>>for
> >>>>each distro? I think it would help alot if we could be more
> >>>>friendly
> >>>>to
> >>>>DEVs.
> >>>>
> >>>>-- bk
> >>>>
> >>>>_______________________________________________
> >>>>katello-devel mailing list
> >>>>katello-devel at redhat.com
> >>>>https://www.redhat.com/mailman/listinfo/katello-devel
> >>>>
> >>>
> >>>I said half jokingly on IRC the other day that we should have a
> >>>'katello-configure --developer' which would install everything for
> >>>use with a git checkout. This would make it completely simple for
> >>>anyone to get up and going with a dev setup. Perhaps they would just
> >>>point to the git checkout:
> >>>
> >>>% katello-configure --developer /home/dudette/katello
> >>>
> >>>_______________________________________________
> >>>katello-devel mailing list
> >>>katello-devel at redhat.com
> >>>https://www.redhat.com/mailman/listinfo/katello-devel
> >>>
> >>
> >>There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns.
> >>
> >>Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer.
> >>
> >>Mike
> >>
> >>_______________________________________________
> >>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
More information about the katello-devel
mailing list