Language specific mirrors for Fedora Playground compliant packages

Vít Ondruch vondruch at redhat.com
Mon Sep 15 14:40:43 UTC 2014


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 "https://fedora-rubygems-mirror.org" instead of standard "source
> "https://rubygems.org"" 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.
>
> 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.
>
> 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.
>
> 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.


Vít



More information about the env-and-stacks mailing list