Language specific mirrors for Fedora Playground compliant packages

[Nick Coghlan]

On 09/16/2014 03:26 PM, Radek Vokál wrote:
> ----- Original Message -----
>> Dne 15.9.2014 15:34, Vít Ondruch napsal(a):
>> $ 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.

For the folks that use pure noarch packages, this is true. There are
also various mechanisms for separating the build servers from the
production servers (like wrapping up entire virtual environments as
system packages:
https://hynek.me/articles/python-app-deployment-with-native-packages/)

It's not without it's problems though, and that's what I think
Env&Stacks is in a great position to solve by bringing upstream and
downstream contributors together to come up with a more coherent
solution, rather than each side continuing to work around the other.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

HSS Provisioning Architect