Re: Let's discuss big changes in Ruby packaging for squeeze+1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
On Apr 21, 2010, at 2:07 PM, Lucas Nussbaum wrote:
0) We try to provide as much support as possible for all ruby
interpreters
(well, at least 1.8 and 1.9.1, but maybe also jruby). However, we
decide
on a default version (1.8 currently) that all libraries must
support.
I saw 1.9.2 mentioned later in this thread. Considering 1.9.1 doesn't
work well with Rails 3 (I hear, I haven't tried), if Debian is to have
Rails 3, 1.9.2 should be the 1.9 version, no?
1) We base our packaging on rubygems. This doesn't mean that we
package gems
directly. But we take upstream gems, convert them to .orig.tar.gz
(easy), and
then apply our Debian-specific tools. That allows use to keep the
maximum flexibility of what we can do with the source (patching, etc).
This is good, and there's a new project that may be of interest:
http://github.com/rtomayko/rpg
I personally don't like that distributing Ruby libraries is such a
mess that the packaging wheel is reinvented all the time, but this
project looks good.
2) Instead of installing to /usr/lib/ruby/1.{8,9.1}, we install to:
/usr/lib/ruby/vendor_ruby/ <= libraries that support all versions
of the interpreter
/usr/lib/ruby/vendor_ruby/1.8 <= libraries that only support 1.8
/usr/lib/ruby/vendor_ruby/1.9.1 <= libraries that only support 1.9.1
That allows to make a better difference between the stdlib and the
third-party libraries.
Can we also please have RubyGems on Debian install in /usr/local/lib/
site_ruby, with binaries in /usr/local/bin? The installation location
of the current RubyGems is considered messy and unexpected, and
binaries are not in the default $PATH.
Otherwise, this sounds similar to a suggestion I made a few weeks ago,
so I like it ;-).
5) Regarding test suites, we should really try to execute them
during the
build (for every ruby implementation), as this will allow to detect
regressions.
We need to determine which test suites are acceptable. Do we simply do
'rake test' or 'rake spec'? Or try to determine from the Rakefile
which? A lot of projects are using Cucumber, too, but I think its use
should be avoided when building packages because it often has more
intrusive development/build dependencies because of integration type
tests.
For example, Chef uses:
* Rspec - Unit/functional testing
* Cucumber - Integration testing
Rspec is pretty straightforward, but for running Chef's Cucumber
suite, it needs to have a full sandboxed Chef server environment
including CouchDB, RabbitMQ, and SOLR. Obviously this isn't the case
for every Ruby project, and package maintainers can probably determine
which test suite(s) for a project to run.
+ various QA scripts, including one to grep for "require 'rubygems'"
Suggestion: Such a script should also look for 'bundler' and other gem-
specific dependency handling as well. For example, merb has
'dependency' methods.
- --
Opscode, Inc
Joshua Timberman, Senior Solutions Engineer
C: 720.334.RUBY E: joshua@opscode.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
iEYEARECAAYFAkvQY4UACgkQO97WSdVpzT3UxwCcD0IpIpXWgkJTfPJlwWXNt3s4
mBQAoIeOtl4UpLE5/CwuuMTPSJapPVtH
=zAOy
-----END PGP SIGNATURE-----
Reply to: