Language specific mirrors for Fedora Playground compliant packages

Radek Vokál rvokal at
Tue Sep 16 05:26:43 UTC 2014

----- Original Message -----
> Dne 15.9.2014 15:34, Vít Ondruch napsal(a):
> > Hi Nick
> >
> > Dne 15.9.2014 10:19, Nick Coghlan napsal(a):
> >> As mentioned in my self-introduction email, I'm interested in the idea
> >> of filtered Fedora provided mirrors of PyPI/RubyGems/etc that contained
> >> only packages that had been through Fedora Playground levels of review.
> >>
> >> Having such selective mirrors available would mean that we could freely
> >> choose between using the language level packaging tools and RPMs on a
> >> project by project basis without having to recheck the licenses
> >> ourselves. It would also provide a way for us to easily share the
> >> results of our own licensing reviews when we bring in new dependencies
> >> from upstream.
> > While you plot this nicely and it sounds attractive, I am really against
> > this idea. Here are a few points which comes to my mind:
> >
> > 1) Speaking of Rubyists, you would need to convince them to start using
> > "source "" instead of standard "source
> > """ in their Gemfiles. Not sure how you would like
> > to achieve this. We could patch Bundler somehow to substitute the
> > original source on Fedora, but I don't want to imagine what source of
> > problems it would bring.

IIRC that's what Maven does already. 

> >
> > 2) In Fedora, there are packages, which are modified from upstream
> > versions. For example, rubygem-listen [1] provides universal API to
> > provide notifications about file changes on file system. Upstream
> > decided, that they will have hard dependencies on other platform
> > specific libraries, which supports FS level notifications. We decided to
> > drop them, since it does not make sense to support libraries which does
> > nothing on Linux. Sometimes, we are forced to override overly tight
> > dependencies on other libraries. And now to the question. What would
> > happened with such gem? What the mirror should provide in such case?
> > Fedora's version or upstream version of gem? The former is quite
> > dangerous idea, since it would end up in two different packages of the
> > same version.

The idea is that the content provided by Fedora/RHEL/CentOS can be still modified/patched version of upstream content. If we can automate most of the work, that's great but I'm pretty sure we will have to maintain patches for various components. We will still be downstream.

> >
> > 3) You need additional human/infrastructure resources.
> >
> > Additionally to the point 3, if you have such resources, I would be
> > better to invest them into development of proper support of multiple
> > versions of packages in DNF. That would remove the need for most of the
> > SCLs and additional repositories in Copr, at least speaking of Ruby
> > ecosystem.

Vitku, seems like we need another meeting. Nick, would you be interested in joining it? There are various requirements from both the software management side as well as from Developers/Users and we need to find a the best approach which suits developer needs and still supports admins and the way they manage the system. The main idea for developers was "Use what they're used to and support it on the OS" (which actually applies for admins as well)

> >
> > Nowadays, people are not using ruby193 collection, because they are in
> > love with Ruby 1.9.3. They are using the collection since it is bundled
> > with Ruby on Rails 3.2. And they are using SCLs just because it allows
> > them to install more versions of RoR on single system, not because they
> > believe that their worflow is now much easier. But you can achieve it
> > just fine with rpm -i having the RPMs. It is just not supported by
> > DNF/YUM, since DNF/YUM understands just "upgrade, don't leave old
> > version on system".
> >
> >
> BTW I forgot to mention one issue. "gem install" or "bundle --install"
> works just fine for every user. But the issue is with binary extensions.
> What should I do to install sqlite3 gem for example:
> $ gem install sqlite3
> Fetching: sqlite3-1.3.9.gem (100%)
> Building native extensions.  This could take a while...
> ERROR:  Error installing sqlite3:
>     ERROR: Failed to build gem native extension.
>     /usr/bin/ruby extconf.rb
> mkmf.rb can't find header files for ruby at /usr/share/include/ruby.h
> Gem files will remain installed in
> /home/vondruch/.gem/ruby/gems/sqlite3-1.3.9 for inspection.
> Results logged to
> /home/vondruch/.gem/ruby/gems/sqlite3-1.3.9/ext/sqlite3/gem_make.out
> There are two answers:
> 1) yum install rubygem-sqlite3
> 2) gem instal gem-nice-install && gem install sqlite3
> where yum install knows everybody on Red Hat platform, gem-nice-install
> knows virtually nobody. And to be honest, even me as a rubyist prefer 1)
> since I have *no* compiler on my system and I hope it stays like that.

That's surprising to me cos I'm being told that maven, ruby, nodejs developers prefer the upstream management tools for various reasons and they are not in favor of RPMs.


> Vít
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks at

More information about the env-and-stacks mailing list