RPM and GEMS - Unholy marriage
by Bert Meerman
Hi everyone,
I've been following the discussion on RPM and GEMS conflict of interest.
I found it quite interesting, and I would like to discuss some packaging
options already present within ruby and rails.
There are three things I would like to add to Jeroen's page:
1) A valid Rails RPM package *explicit* links to gems required.
Strictly speaking, you can lazy load the gems an application needs. This
might work, especially if you use gems that are very common (like
Rails). Problem is, that a critical dependency is missing. You can add
this info in the RPM spec, but I think it is better to make it mandatory
more downstream. For RPM packaging, all you need to do is ask for the
dependent gems.
My question: what are your thoughts on this?
2) A valid Rails RPM package must contain the version when specifying
gems and the version must be limited.
Example:
# require 'aws/s3'
config.gem 'aws-s3', :lib => 'aws/s3', :version => '0.4.0', #
:source => "http://code.whytheluckystiff.net"
(see also
http://api.rubyonrails.org/classes/Rails/Configuration.html#M002064)
This means that the module will use any version greater than 0.4.0. You
can also specify smaller, a range or a specific number. The trick is
this: if you do this correctly, you can use multiple gem versions on the
same system. In theory, this must work. This is what was causing the
issue with Lighthouse. I think you should fix the version or make it a
range, never a 'greater than' (as in the example and with Lighthouse).
My question: what are your thoughts on this, especially the mandatory
'limit the version number'?
3) Gems can be vendorized.
OK, this is the moment where a lot of people are going to be amazed,
mouth open and staring at the screen for the next five minutes: you can
make a Rails application and include the gems in it, as it where local
code. This is called vendorization. A vendorized gem is only available
to the application using it: it is part of the source code of that
application and located in the /vendor directory of the application root
(not in the normal gem directory). In fact, you can vendorize a gem and
then even modify the code.
On one hand, if you say all gems should be vendorized, you don't have
any version conflicts. On the other hand, I heard someone complain about
static linking...
Personally, I disagree with the vendorization of gems. It obfuscates
version management.
Question: does Fedore prefer (or mandatorize) a specific approach? Why?
Thanks in advance,
Bert
13 years, 10 months
Current ruby 187 srpm status?
by Mamoru Tasaka
( For this contents, I post also to ruby-sig)
Mamoru Tasaka wrote, at 06/29/2010 02:24 AM +9:00:
> Jim Meyering wrote, at 06/29/2010 01:49 AM +9:00:
>> http://meyering.net/private/ruby-1.8.7.299-3.el6.src.rpm
By the way, currently whose srpm are we planing to use for rawhide now?
http://meyering.net/private/ruby-1.8.7.299-3.el6.src.rpm or
http://mo.morsi.org/files/ruby-1.8.7.299-1.fc13.src.rpm ?
Unifying these is much preferable for maintenance.
And, comments to both srpm:
- Please don't define %ruby_sitelib and %ruby_sitearch as below:
----------------------------------------------------------------------------
%{!?ruby_sitelib: %global ruby_sitelib %{ruby_vendorlib}/site_ruby}
%{!?ruby_sitearch: %global ruby_sitearch %{ruby_vendorarch}/site_ruby}
----------------------------------------------------------------------------
These definitions are confusing compared to this:
https://fedoraproject.org/wiki/Packaging/Ruby
In ruby related spec file, we always define %ruby_sitelib, %ruby_sitearch
as:
----------------------------------------------------------------------------
%{!?ruby_sitelib: %global ruby_sitelib %(ruby -rrbconfig -e 'puts Config::CONFIG["sitelibdir"] ')}
%{!?ruby_sitearch: %global ruby_sitearch %(ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"] ')}
----------------------------------------------------------------------------
On i686 these are expanded as /usr/lib/ruby/site_ruby/1.8 and
/usr/lib/ruby/site_ruby/1.8/i386-linux .
Please rename these macros in ruby.spec (like %sitelibbase %sitearchbase or so)
Regards,
Mamoru
13 years, 10 months
RPM and GEMS conflict of interest
by Gilles Dubreuil
Hello,
I've been asking myself why there bother with rubygem packages?
Gems have a different life cycle and are completely managed through the
gem interface:
Basically if one can do a
# yum install rubygem-rails
then one can do a
# gem install rails-2.3.8
But with gem one can also do
# gem install rails-2.3.3
Up to the rails application to specify which version (or library) to
use.
So gems of different versions can coexist where rubygems rpms of
different versions cannot be installed the same way and is redundant.
Assuming they can be installed in parallel then there is an issue with
the package name not showing the gem version i.e rubygem-rails.noarch.
So I ended wondering why maintain rubygems rpms at all, once ruby is
installed along with rubygems package then gem handles the rest.
I'm sorry if this discussion has been brought earlier but it doesn't
make sense for me.
Thanks for thoughts.
Gil
13 years, 10 months
need some clear explain for current ruby package
by tommy xiao
FYI, where to easy get rpm list for current fedora 13.because if i first
need get this rpm,i use google cant find this path or way.
2. if i want to contribute this ruby packge, if any guide can find? in
ruby-sig wiki,i cant find more interest topic.
i am rubyist,so i have no more fedora experience.so i need enhance this
ability.any tutorial welcome
best regards
--
tommy xiao
E-mail: xiaods(AT)gmail.com
13 years, 10 months
Fwd: Re: ruby 1.8.7.x for rawhide
by Mo Morsi
Sorry, it doesn't seem like my original response made it through (at
least not according to the ruby-sig archive
http://lists.fedoraproject.org/pipermail/ruby-sig/2010-June/thread.html). Resending.
-Mo
-------- Original Message --------
Subject: Re: ruby 1.8.7.x for rawhide
Date: Fri, 18 Jun 2010 12:44:56 -0400
From: Mohammed Morsi <mmorsi(a)redhat.com>
To: Ruby SIG mailing list <ruby-sig(a)lists.fedoraproject.org>
CC: Mamoru Tasaka <mtasaka(a)ioa.s.u-tokyo.ac.jp>,
ruby-owner(a)fedoraproject.org
Hey Mamoru,
Appreciate the efforts. I am also working towards Ruby 1.8.7 on
Fedora, just released a SRPM/SPEC a few days ago that I was working on
http://mo.morsi.org/blog/node/318
Just fyi, we're also going to need this patch
http://redmine.ruby-lang.org/repositories/diff/ruby-187?rev=27408
To get rails 3.0.0 working against Ruby 1.8.7p149
http://redmine.ruby-lang.org/issues/show/2557
I'm currently working on bundling Rails 3 into rpms and creating a
Fedora based virtual appliance w/ Ruby 1.8.7 on it, similar to the one I
released w/ Ruby 1.9, to make testing software against multiple versions
of Ruby on Fedora as simple as possible. After that I'm planning on
setting up an automated test system to test the various Ruby packages we
have in Fedora against each appliance.
Stay tuned for updtes.
-Mo
13 years, 10 months
ruby 1.8.7.x for rawhide
by Mamoru Tasaka
Hello, all:
Currently kanarip is working on ruby 1.9.x, trying to import ruby 1.9.x packages
into Fedora rawhide, and I fully appreciate his work.
However
- still many softwares (including packages I maintain like alexandria) don't
support ruby 1.9.x
- when importing ruby 1.9.x into Fedora, writing packaging guidelines when using
ruby 1.9.x is needed.
- and maybe ruby 1.9.x is enough stable, however I don't know well (kanarip?)
- and I guess currently many users 1.8.x
So I guess still ruby 1.8.x should be the main branch for F-14 (anyway kanarip
is trying to make ruby 1.9.x parallel-installable).
On the other hand, now ruby 1.8.6.x became rather old and some packages (like
rubygem-nokogiri) decided to stop supporting ruby 1.8.6.x.
So I want to update ruby to 1.8.7.x first, at least on rawhide.
Test rpms of ruby 1.8.7.x for rawhide (and for F-13) are under:
http://mtasaka.fedorapeople.org/ruby187/
(repodata also available)
I appreciate it if you would test these packages. It is expected that
people using ruby 1.8.6.x can upgrade ruby (and its subpackages) to ruby 1.8.7.x
without problems, and without compiling anything against new ruby rpms.
If these packages seem good, I would like to update rawhide ruby to 1.8.7.x
in 10 days or so.
( I think upgrading ruby in F-13 to 1.8.7.x is quite debatable, however
it seems ruby 1.8.7.x is enough stable and our 1.8.6.x srpm has
many backports from 1.8.7 or 1.8.x branches and updating ruby to 1.8.7.x even
on F-13 makes it easier to maintain )
( By the way the ruby 1.8.7.x srpm I used for rawhide/F-13 also compiles
on F-12 )
Regards,
Mamoru
13 years, 10 months
Building 1.9.1 on CentOS 5.5
by Robin Bowes
Hi,
I just tried to rebuild ruby-1.9.1.378-16.el5.fr191.src.rpm on CentOS
5.5 and get this error:
+ autoconf
configure.in:4: error: Autoconf version 2.60 or higher is required
configure.in:4: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
error: Bad exit status from /var/tmp/rpm-tmp.92052 (%build)
Note that this is the el5 package.
Can that requirement be relaxed, ie. will it work with autoconf-2.59-12
that is available on RHEL/CentOS 5.5 ?
R.
13 years, 10 months
Fedora / Ruby 1.9 appliance
by Mo Morsi
Just figured I'd share this here incase anyone is interested but not
subscribed to Fedora Planet.
http://mo.morsi.org/blog/node/316
I just released a Fedora based virtual appliance w/ a Ruby 1.9.1 based
rpm stack. To get there I managed to get ruby-shadow to compile against
Ruby 1.9.1, released updated rubygems and rubygem-rake packages
compatible w/ Ruby 1.9 (they are just empty packages now which depend on
Ruby, as Ruby 1.9 ships w/ gem & rake), and pushed alot of updates to my
polisher and polisher-scripts projects.
http://github.com/movitto/polisher
http://github.com/movitto/polisher-scripts
All updated rpms were built in mock against the Ruby 1.9 rpm, so when
you run a ruby-gnome app for example, your running against the latest
gnome2 lib that ships w/ Fedora as well as the Ruby 1.9 libraries.
To start the appliance, simply extract the tarball and run "sudo
virt-image polisher-devel.xml". Then simply bring up virt-manager for
graphical access to the vm.
Many thanks to all on this list for all the work so far which I
leveraged to build this appliance. There is alot more todo, I want to
eventually get every Ruby project in Fedora built against 1.9.1, and try
to get a Ruby 1.8.7 appliance up and running, but this should help
anyone looking to start running software against a native Fedora/Ruby
1.9.1 stack.
Enjoy.
-Mo
13 years, 11 months
