rpm package for ruby gems

[Aditya Prakash]

>
> Also, some of the packages you list above are what I'd class as
> development or test packages, which should be much lower priority for
> you.  Focus on packaging runtime dependencies and you'll get there quicker.


Yeah, non-test, non-development ones seem to be more available than others.
Thanks for links btw, Dominic.

we update Ruby on Rails
> and many other gems. That means all packaged applications have to be
> updated as well. And that's why we
> have only one Rails app in Fedora.


Now there are two ;) I promise I will help with packaging. And don't worry
Sarup, I will do it on my own time.

A production ready application with unpackaged dependencies > one with all
> dependencies packaged but won't see use because of unfinished crucial
> features. The reverse would be true if we had several people working on the
> project simultaneously,

We will also need to bring Kushal on board with this.

Thanks a lot guys. You have been really helpful. I will read everything and
get back to you if I need help.

Aditya


On Fri, May 29, 2015 at 11:45 PM, Sarup Banskota <sbanskota08 at gmail.com>
wrote:

> Very resourceful discussion.
>
> I have zero experience with packaging stuff myself, so what I may write in
> this email might be naive thinking.
>
> My short-term suggestion: IMO, you should continue with your work as usual
> on the git server and SparkleShare side of things for now. A production
> ready application with unpackaged dependencies > one with all dependencies
> packaged but won't see use because of unfinished crucial features. The
> reverse would be true if we had several people working on the project
> simultaneously, because someone's time spent packaging would mean another
> could work on features. Right now it's mostly you doing any programmatic
> activity, so how you spend your time affects when we can let people use it.
>
> Once we're into production ready phase, we can do two things in parallel:
> one, try to work with any feedback we may receive and two, start with
> packaging production gems (following the process Ken laid out). In fact,
> when it's visible people are using the application, we're more likely to
> see folks from the Ruby SIG want to guide us package gems, and we could
> definitely use that guidance.
>
> >
> > Phase 1) Create an RPM that more-or-less follows all the packaging
> > guidelines, but bundles all its dependencies. You can build/ship this
> > RPM via Copr.
> >
> > Phase 2) Switch your application from using Bundler to using
> > https://rubygems.org/gems/bundler_ext
> >
> > Phase 3) Start dropping your bundled gems one by one and use the
> > system gems instead.
> >
> > In hindsight I wish that I had taken this approach with Gitorious or
> > Gitlab, instead of only starting at the base of the dependency tree
> > and working my way upwards. It's probably good to work from both
> > directions at once. But starting at the top, with the app itself, will
> > give you the satisfaction and internal motivation of having something
> > that works today, even if it's not up to Fedora's standards.
> >
>
> +1.
>
> What do you think, @Emily?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20150530/a8d7a662/attachment.html>