[DRE-maint] On CDBS and packaging gems

[Filipe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 20 Mar 2007, Lucas Nussbaum wrote:
> On 19/03/07 at 15:15 -0600, Gunnar Wolf wrote:
>> Lucas Nussbaum dijo [Fri, Mar 16, 2007 at 09:05:11AM +0100]:
>
> I don't think that the current user experience with rails and rubygems
> is really satisfying either (see #405789, #403407).

Hum.. so we need to improve rubygems package or tag those bugs as won't
fix :D
>
>> Re-generalizing: I understand working with the Mongrel people might be
>> problematic. But then again, not all Gems authors will be this way. It
>> will be easier for us to interface with the Ruby world if we have a
>> standard way of dealing with Gems. And, at the political level, we
>> will still get to deal with each author. Some might be quite thrilled
>> to be in Debian.
>
> Yes, but such upstream authors (that is, gem authors that would be quite
> thrilled to be in Debian) will probably agree to distribute their
> software in a .tgz.
>
> I've had a look at mongrel's source. They use setup.rb and rake. And
> their Rakefile states:
> task :gem_source do
>  mkdir_p "pkg/gems"
>
>  FileList["**/*.gem"].each { |gem| mv gem, "pkg/gems" }
>  FileList["pkg/*.tgz"].each {|tgz| rm tgz }
>  rm_rf "pkg/#{name}-#{version}"
>
>  sh %{ index_gem_repository.rb -d pkg }
>  sh %{ scp -r ChangeLog pkg/* rubyforge.org:/var/www/gforge-projects/mongrel/releases/ }
> end
>
> So they already create a .tgz, they just remove it before uploading it
> to rubyforge.org. It's not going to kill them to keep that .tgz instead
> of removing it...

Yes, I've sent upstream a patch([1]) that provides the tgz file. Maybe
the next version of mongrel will have a tgz file released too (if Zed
doesn't forget to apply my patch) - I'll keep remembering him, and gwolf
knows how it can be borring :D

But besides Mongrel, others gems can appear, and we will need to
deal with them someday.

>
>> The CDBS class I'm suggesting might be parallel to dh-make-perl, which
>> I co-maintain: A script that makes it easier for you to integrate a
>> Perl module in Debian. CPAN has its own packaging/versioning scheme,
>> but it's far easier (for Debian people) to set up their unpackaged
>> modules with a helper as dh-make-perl - and it should prove the same,
>> I guess, for Rubyists with this class.
>
> I would really prefer if upstream authors were first pushed into
> providing a .tgz. But if he want to do the work to package gems, why not
> :-)
>
> What about just repackaging the .orig.tar.gz from the gem ? Wouldn't
> that solve the problem for most gems ? (ie those who include a setup.rb
> in the gem)

Well well... we can go this way... but is this the prettier way? If so,
maybe we should think in put a note about this in our web site or
another place, and ruby-pkg-tools could do this for us. What about it?

1. http://rubyforge.org/tracker/index.php?func=detail&aid=7876&group_id=1306&atid=5147


Regards,

filipe {
  @             icewall.org
  GPG        1024D/A6BA423E
  Jabber  lautert at jabber.ru
}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF/8almKFbPqa6Qj4RAlZtAJ9y97V5zwYRafhLJnSgk8Bk2EH84ACfbPdj
gZRjLzwmDH81iIQc1xgDBwg=
=MKe4
-----END PGP SIGNATURE-----