Re: Let's discuss big changes in Ruby packaging for squeeze+1
On 15/05/10 at 09:45 -0300, Antonio Terceiro wrote: I tried, but when I reached the point of trying it in the browser, I ended up noticing that there was a hidden dependency of librestclient-ruby1.8 on libopenssl-ruby1.8. On Squeeze, libopenssl-ruby1.8 is included in libruby1.8, but on Lenny it has its own package. I've fixed this in the backport, can you please upload it? Done -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100517080737.gb9...@xanadu.blop.info
Re: Let's discuss big changes in Ruby packaging for squeeze+1
Lucas Nussbaum escreveu isso aí: On 15/05/10 at 09:45 -0300, Antonio Terceiro wrote: I tried, but when I reached the point of trying it in the browser, I ended up noticing that there was a hidden dependency of librestclient-ruby1.8 on libopenssl-ruby1.8. On Squeeze, libopenssl-ruby1.8 is included in libruby1.8, but on Lenny it has its own package. I've fixed this in the backport, can you please upload it? Done Thanks. :) -- Antonio Terceiro terce...@softwarelivre.org http://softwarelivre.org/terceiro signature.asc Description: Digital signature
Re: Let's discuss big changes in Ruby packaging for squeeze+1
Tobi escreveu isso aí: .. and another small patch, setting the html encoding to utf-8, because the gem info might contain utf-8 characters. See e.g. nokogiri. Tobias Applied, thanks. :) -- Antonio Terceiro terce...@softwarelivre.org http://softwarelivre.org/terceiro signature.asc Description: Digital signature
Re: Let's discuss big changes in Ruby packaging for squeeze+1
... and another small patch, setting the html encoding to utf-8, because
the gem info might contain utf-8 characters. See e.g. nokogiri.
Tobias
From 049447d5b844e91e997939f134271ce223d7146e Mon Sep 17 00:00:00 2001
From: etobi g...@e-tobi.net
Date: Mon, 10 May 2010 08:18:14 +0200
Subject: [PATCH 2/2] Set html encoding to utf-8
---
gemwatch.rb |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gemwatch.rb b/gemwatch.rb
index 24c6c89..6bd67c8 100644
--- a/gemwatch.rb
+++ b/gemwatch.rb
@@ -143,6 +143,7 @@ __END__
@@ layout
%html
%head
+%meta{http-equiv = content-type, :content = text/html;charset=UTF-8}
%link{:rel = stylesheet, :type = text/css, :href = asset_url(/style.css)}
%body{:class = @body_class}
%div.wrap
--
1.7.1
Re: Let's discuss big changes in Ruby packaging for squeeze+1
Antonio Terceiro wrote:
In the meantime, the current version is running on
http://gemwatch.heroku.com/
Thanks a lot!
I just noticed, that the timestamps of the files in the tarball are set to
1970-01-01, which would cause lintian errors if such tarball is used as
upstream source.
Unfortunately it seems, gem's don't care about the timestamps. I took a
look at the rubygems source code and it probably might be easy to fix
this, but for now I think the best way would be to touch all files. See
the attached patch.
Tobias
From 23915dc23bae2a8627332f7481890b8a4b0cd52e Mon Sep 17 00:00:00 2001
From: etobi g...@e-tobi.net
Date: Sun, 9 May 2010 22:58:52 +0200
Subject: [PATCH] Update timestamps in extracted tarball
---
README.rst |1 +
gemwatch.rb |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/README.rst b/README.rst
index 64a1d8d..b8b3a6b 100644
--- a/README.rst
+++ b/README.rst
@@ -27,6 +27,7 @@ steps::
wget ./mygem-0.1.0.gem
tar xf mygem-0.1.0.gem
tar xzf data.tar.gz
+ find . -exec touch {} \;
xcat metadata.gz metadata.yml
rm -f mygem-0.1.0.gem data.tar.gz metadata.gz
cd ..
diff --git a/gemwatch.rb b/gemwatch.rb
index 2c2acfc..24c6c89 100644
--- a/gemwatch.rb
+++ b/gemwatch.rb
@@ -61,6 +61,7 @@ class GemWatch::Gem
run wget #{uri}
run tar xf #{gem}
run tar xzf data.tar.gz
+FileUtils.touch(Dir.glob('**/*'))
run zcat metadata.gz metadata.yml
FileUtils.rm_f([gem, data.tar.gz, metadata.gz])
end
--
1.7.1
Re: Let's discuss big changes in Ruby packaging for squeeze+1
Antonio Terceiro escreveu isso aí:
Lucas Nussbaum escreveu isso aí:
On 22/04/10 at 11:14 -0300, Antonio Terceiro wrote:
Lucas Nussbaum escreveu isso aí:
- write a set of scripts to package from gems, including:
+ gem2tgz - convert gem to tgz, saving the gem metadata somewhere
+ dh_make_ruby - prepare a source package, making use of the gem
metadata
+ script to watch gems on rubygems.org (for debian/watch)
+ various QA scripts, including one to grep for require 'rubygems'
These got me a itch to scratch, and I decided to play a little. It seems
we have something that solves the gem2tgz and the debian/watch items:
http://gemwatch.heroku.com/
It can be used with debian/watch files like this:
version=3
http://gemwatch.heroku.com/${gem} /download/${gem}-(.*)\.tar.gz
Source is available on github:
http://github.com/terceiro/gemwatch
All dependencies are available on Debian sid.
Do you think it would be possible to make it available from alioth, in
the project's website, possibly after backporting a few packages?
I think it is possible, yes. I'll work on it as soon as can.
Also note that system() doesn't check the return value. It might be
better to check $? after each call, since we clearly want to check for
failures.
Sure. I guess I'll change most of those calls into File and FileUtils calls
when possible, and check errors properly otherwise.
So, Gemwatch now runs as CGI and can be made available on alioth.
I've also made the backports necessary to run it on Lenny:
http://alioth.debian.org/~terceiro-guest/backports/libmime-types-ruby_1.16-2~bpo50+1.dsc
http://alioth.debian.org/~terceiro-guest/backports/librestclient-ruby_1.4.2-1~bpo50+1.dsc
http://alioth.debian.org/~terceiro-guest/backports/libsinatra-ruby_1.0.a-1~bpo50+1.dsc
The interdiffs between those backports and the ones in squeeze are here:
http://alioth.debian.org/~terceiro-guest/backports/interdiffs/
I guess the alioth admins will require those packages to be properly
uploaded to backports.org, right? In that case I'll need sponsoring.
I am also not sure whether it is usefull to inject those packages in the
team repository, and where to put them (I guess
branches/$package/lenny-backports or something, but would like to hear
from others).
In the meantime, the current version is running on
http://gemwatch.heroku.com/
--
Antonio Terceiro terce...@softwarelivre.org
http://softwarelivre.org/terceiro
signature.asc
Description: Digital signature
Re: Let's discuss big changes in Ruby packaging for squeeze+1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 23, 2010, at 2:10 AM, Lucas Nussbaum wrote: No, we can't install packages ourselves (that are not in the build-depends) during the build. Is the point actually that we can't /uninstall/ Build-Depends during the build? - -- Opscode, Inc Joshua Timberman, Senior Solutions Engineer C: 720.334.RUBY E: jos...@opscode.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkvRq8sACgkQO97WSdVpzT0MhwCfWNEWw1W3Od+su3MeXAj9BsfI +m0AnjGpyoCOtPX+nhq9SCvKN5rN7sak =JweF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9376f0e1-e8a7-4ae0-a037-8f65720d7...@opscode.com
Re: Let's discuss big changes in Ruby packaging for squeeze+1
On 23/04/10 at 08:16 -0600, Joshua Timberman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 23, 2010, at 2:10 AM, Lucas Nussbaum wrote: No, we can't install packages ourselves (that are not in the build-depends) during the build. Is the point actually that we can't /uninstall/ Build-Depends during the build? The build is done by sbuild. sbuild installs the packages specified in Build-Depends: as root, then extracts the source package, then calls the relevant debian/rules targets, but as a normal user. Since the targets are called as a normal user, we are in no position to modify the list of install packages during the build. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100423175008.gb19...@xanadu.blop.info
Re: Let's discuss big changes in Ruby packaging for squeeze+1
On 22/04/10 at 00:11 +0200, Tobi wrote:
Lucas Nussbaum wrote:
3) Instead of providing several libfoo-ruby1.{8,9.1} packages, we
provide only one when it is possible (pure ruby packages), named
libfoo-ruby.
When this is not possible (case of packages that contain native extensions),
we continue to provide several binary packages libfoo-ruby1{8,9.1}.
What about 1.8-only packages? I only know of libparstree wich will
probably never be available for 1.9 [1]. Does it make sense to keep such
1.8-only packages around?
Yes, probably until 1.9 is really the new default version.
libparstree is required by libheckle which is used by rspec. My vague
plans for squeeze+1 were to drop libparstree/libheckle alltogether, if I
don't find a way to make them work with 1.9.1.
Apparently, rspec doesn't require parsetree itself, but some packages
require it in their spec files. The Ruby release plans are too unclear
to bet on anything regarding 1.9.X vs 1.8 as the default Ruby version
for squeeze+1.
If 1.9.X becomes the real new stable version, we can of course drop all
1.8 packages.
--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100422062042.gb9...@xanadu.blop.info
Re: Let's discuss big changes in Ruby packaging for squeeze+1
Lucas Nussbaum escreveu isso aí: 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). I'd say let's do this when needed. There are still some upstreams that care enough to release tarballs. -- Antonio Terceiro terce...@softwarelivre.org http://softwarelivre.org/terceiro signature.asc Description: Digital signature
Re: Let's discuss big changes in Ruby packaging for squeeze+1
On 22/04/10 at 19:40 +0900, NARUSE, Yui 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.
We'll release Ruby 1.9.2 in this summer.
Sure, but that doesn't mean that the community will adopt it as a
replacement for ruby1.8. I hope it will be the case, of course.
So where 1.9.2 will install, /usr/lib/ruby/1.9.1 or /usr/lib/ruby/1.9.2?
Note that 1.9.2 intends to have ABI compatibility to 1.9.1.
It is likely that ruby1.9.2 will replace ruby1.9.1 if it is
ABI-compatible.
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.
What will you do about a gem supports 1.8 and 1.9.1 but not 1.9.2.
Since it's ABI-compatible, it shouldn't exist, no? :-)
Anyway, we have two solutions here:
- install in vendor_ruby/1.8 and vendor_ruby/1.9.1 (possibly with
symlinks to reduce disk space)
- ignore the problem, and install it in vendor_ruby/ (similar to what is
done for Java in Debian)
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.
MRI's test-all has some stress test.
Yes, and we run them during build. But I was talking about test suite
shipped by libraries.
--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100422133212.ga...@xanadu.blop.info
Re: Let's discuss big changes in Ruby packaging for squeeze+1
On 22/04/10 at 07:33 -0600, Marcelo E. Magallon wrote:
When I was exploring a similar idea, I was thinking of going
with:
DIR=`basename $gem .gem`
mkdir $DIR
tar xOf $gem data.tar.gz | tar -C $DIR -xzf -
My own implementation:
#!/bin/bash
set -x
set -e
GEM=$1
BASENAME=$(basename $GEM .gem)
TDIR=$(mktemp -d /tmp/gem2tgz.XX)
mkdir $TDIR/$BASENAME
tar xf $GEM -O data.tar.gz | tar xz -C $TDIR/$BASENAME
tar xf $GEM -O metadata.gz | gunzip $TDIR/$BASENAME/metadata
# Fix timestamps of files
find $TDIR/$BASENAME -exec touch -m {} \+
tar czf $BASENAME.tgz -C $TDIR $BASENAME
rm -rf $TDIR
And using the gem metadata to extract things like the gem name,
version, etc.
But then I realised that it's better to use Rubygem's library,
which allows for something like:
require 'rubygems/format'
format = Gem::Format.from_file_by_path ARGV.first
spec = format.spec
puts Gem: #{spec.name} (#{spec.version})
format.file_entries.each do |entry, data|
# entry['path'] is the file's path
# entry['mode'] is the file's mode
# data contains the actual file data
# you only need to add sanity checks and filters here and
# write data to entry['path']
end
It's a real pity that the gem spec does not include the license
information in a machine readable format.
The problem with using the gem library is that I usually prefer not to
have it installed, to make it easier to detect usages of require
'rubygems'. Maybe we should have our own private copy of just
rubygems/format for that.
--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100422134212.ga...@xanadu.blop.info
Re: Let's discuss big changes in Ruby packaging for squeeze+1
(2010/04/22 22:32), Lucas Nussbaum wrote:
On 22/04/10 at 19:40 +0900, NARUSE, Yui 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.
We'll release Ruby 1.9.2 in this summer.
Sure, but that doesn't mean that the community will adopt it as a
replacement for ruby1.8. I hope it will be the case, of course.
So where 1.9.2 will install, /usr/lib/ruby/1.9.1 or /usr/lib/ruby/1.9.2?
Note that 1.9.2 intends to have ABI compatibility to 1.9.1.
It is likely that ruby1.9.2 will replace ruby1.9.1 if it is
ABI-compatible.
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.
What will you do about a gem supports 1.8 and 1.9.1 but not 1.9.2.
Since it's ABI-compatible, it shouldn't exist, no? :-)
Anyway, we have two solutions here:
- install in vendor_ruby/1.8 and vendor_ruby/1.9.1 (possibly with
symlinks to reduce disk space)
- ignore the problem, and install it in vendor_ruby/ (similar to what is
done for Java in Debian)
ABI-compatible in MRI means, extension library can link the Ruby.
It's note including Ruby level compatibility.
http://github.com/ruby/ruby/blob/trunk/NEWS
Anyway though 1.9.2 is intended to be almost compatible with 1.9.1,
no one knows how 1.9.3 or later will be.
So symlink solution seems safe.
--
NARUSE, Yui nar...@airemix.jp
--
To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bd05691.8070...@airemix.jp
Re: Let's discuss big changes in Ruby packaging for squeeze+1
On 22/04/10 at 23:00 +0900, NARUSE, Yui wrote:
(2010/04/22 22:32), Lucas Nussbaum wrote:
On 22/04/10 at 19:40 +0900, NARUSE, Yui 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.
We'll release Ruby 1.9.2 in this summer.
Sure, but that doesn't mean that the community will adopt it as a
replacement for ruby1.8. I hope it will be the case, of course.
So where 1.9.2 will install, /usr/lib/ruby/1.9.1 or /usr/lib/ruby/1.9.2?
Note that 1.9.2 intends to have ABI compatibility to 1.9.1.
It is likely that ruby1.9.2 will replace ruby1.9.1 if it is
ABI-compatible.
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.
What will you do about a gem supports 1.8 and 1.9.1 but not 1.9.2.
Since it's ABI-compatible, it shouldn't exist, no? :-)
Anyway, we have two solutions here:
- install in vendor_ruby/1.8 and vendor_ruby/1.9.1 (possibly with
symlinks to reduce disk space)
- ignore the problem, and install it in vendor_ruby/ (similar to what is
done for Java in Debian)
ABI-compatible in MRI means, extension library can link the Ruby.
It's note including Ruby level compatibility.
http://github.com/ruby/ruby/blob/trunk/NEWS
Ah :-) Would be too easy otherwise. Then it's probably better to handle
the 1.9.1-1.9.2 transition in the same way as the 1.9.0-1.9.1
transition.
--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100422143542.ga6...@xanadu.blop.info
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: jos...@opscode.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (Darwin)
iEYEARECAAYFAkvQY4UACgkQO97WSdVpzT3UxwCcD0IpIpXWgkJTfPJlwWXNt3s4
mBQAoIeOtl4UpLE5/CwuuMTPSJapPVtH
=zAOy
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/4068ae0a-b73b-4543-97e5-00aa885b8...@opscode.com
Re: Let's discuss big changes in Ruby packaging for squeeze+1
On 22/04/10 at 08:56 -0600, Joshua Timberman wrote: 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. This has been discussed at length in #448639 (/usr/local/lib vs /var/lib) and #403407 (executables not in $PATH). 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. Using Rake is usually a bit painful, because the Rakefile itself often requires adding dependencies (like rubygems). It's better to keep rubygems out of build dependencies since it allows to detect when the scripts try to use it. 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. The rule should probably be something like: maintainers should make a reasonable effort to run the test suite, provided it's not required to install a myriad of dependencies and set up a complex test environment. + 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. Good idea. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100422152551.gb7...@xanadu.blop.info
Re: Let's discuss big changes in Ruby packaging for squeeze+1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 22, 2010, at 9:25 AM, Lucas Nussbaum wrote: This has been discussed at length in #448639 (/usr/local/lib vs /var/lib) and #403407 (executables not in $PATH). I'm not sure if these bug threads are conclusive, it seems that /usr/ local/lib and /usr/local/bin is preferred to /var/lib, yet the latter is what the RubyGems package does. Using Rake is usually a bit painful, because the Rakefile itself often requires adding dependencies (like rubygems). It's better to keep rubygems out of build dependencies since it allows to detect when the scripts try to use it. It can be, yes. But then the package maintainer has to track down how the unit/spec tests are run and manually set up some other kind of scaffolding to actually execute the tests. I can see the point about keeping rubygems out of the build dependencies, but if we're building packages in a sandboxed environment such as with sbuild, can we not install rubygems, run the tests and then uninstall rubygems? The rule should probably be something like: maintainers should make a reasonable effort to run the test suite, provided it's not required to install a myriad of dependencies and set up a complex test environment. That is fair! Thanks, - -- Opscode, Inc Joshua Timberman, Senior Solutions Engineer C: 720.334.RUBY E: jos...@opscode.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkvQiDoACgkQO97WSdVpzT1bHACfVEl652kRooEYu28v4rFxkoXx JEsAnRjW+HgHeysG80TDW5HIsTrrNvUi =6k4m -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87e8bdb3-eb1b-49db-9498-44ec3774c...@opscode.com
Re: Let's discuss big changes in Ruby packaging for squeeze+1
Hi Marcelo,
Sorry to delay.
So currently repack.sh is getting call with debian/watch file
(uscan --force-download --rename --destdir ../tarballs).
It was a fix for subversion when you download upstream source and keep
it in ../tarballs before running svn-buildpackage.
I haven't said that it will work as it is, but yes we can take this and
modified as per our need. :)
Thanks
Deepak.
On Thu, Apr 22, 2010 at 7:03 PM, Marcelo E. Magallon mmaga...@debian.orgwrote:
On Thu, Apr 22, 2010 at 09:35:14AM +0530, Deepak Tripathi wrote:
2) I have already created a script repack.sh to convert
gemtotar format. we can use this (if it is not buggy). its
available in svn[2]. let me know your input.
Looking at the script, I'm not sure about its purpose:
#!/bin/sh
# Repackage upstream source to exclude non-distributable files
# should be called as repack.sh --upstream-source ver
# downloaded file (for example, via uscan)
set -e
set -u
VER=$2
FILE=$3
PKG=`dpkg-parsechangelog|grep ^Source:|sed 's/^Source: //'`
Does it need an already existing Debian package, or am I
misunderstanding something?
Also:
# Create an extra directory to cope with rootless tarballs
UP_BASE=$DIR/unpack
mkdir $UP_BASE
gem unpack $FILE --target $UP_BASE
If I try for example:
$ gem unpack caper-0.2.0.gem --target $PWD/test-dir
ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions into the /var/lib/gems/1.8 directory.
and test-dir/caper-0.2.0 gets created, but it's empty.
When I was exploring a similar idea, I was thinking of going
with:
DIR=`basename $gem .gem`
mkdir $DIR
tar xOf $gem data.tar.gz | tar -C $DIR -xzf -
And using the gem metadata to extract things like the gem name,
version, etc.
But then I realised that it's better to use Rubygem's library,
which allows for something like:
require 'rubygems/format'
format = Gem::Format.from_file_by_path ARGV.first
spec = format.spec
puts Gem: #{spec.name} (#{spec.version})
format.file_entries.each do |entry, data|
# entry['path'] is the file's path
# entry['mode'] is the file's mode
# data contains the actual file data
# you only need to add sanity checks and filters here and
# write data to entry['path']
end
It's a real pity that the gem spec does not include the license
information in a machine readable format.
Cheers,
Marcelo
--
Deepak Tripathi
E3 71V3 8Y C063 (We Live By Code)
http://deepaktripathi.blogspot.com
