[DRE-maint] On CDBS and packaging gems

[Lucas Nussbaum]

On 19/03/07 at 15:15 -0600, Gunnar Wolf wrote:
> Lucas Nussbaum dijo [Fri, Mar 16, 2007 at 09:05:11AM +0100]:
> > I have been thinking about that again, and I'm still not sure that we
> > want to package such software.
> > 
> > We are talking about software for which upstream said "No, I won't
> > distribute it as something else than a gem".  This is very similar from
> > "No, I won't make the slightlest move to help you get that software in
> > Debian".
> > 
> > Do we really want to support such software ? It seems like it's going to
> > be a maintenance hell. And we have the rubygems package. We can tell our
> > users: "upstream was not willing to make the necessary moves to make it
> > possible to package that software in Debian in a simple way. You can
> > install it at your own risks using the rubygems package."
> 
> I agree with you up to a certain level here: Putting the
> .gem/.orig.tar.gz argument aside, I can assure you the Mongrel guys
> won't be too happy with having an old version of their code in our
> stable Lenny release for a long time - they are agile-fanatic people,
> and stable cycles are not what they excel at ;-)
> 
> But then again, what about our users? Currently, and for all of Etch's
> cycle, Debian's support for Ruby on Rails (which, I don't have to
> emphasize this, is a very attractive technology for many people) will
> be a bit lacking - You can run a Rails app through FastCGI, although
> it's not as easy and fun as it should be, and the Rails world seems to
> be moving over Mongrel. So... Well, it won't be the first time we
> package software not completely blessed upstream (think Mozilla), but
> our users will be benefited by it.

I don't think that the current user experience with rails and rubygems
is really satisfying either (see #405789, #403407).

> 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...

> 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)
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20070320/7be2a594/attachment.pgp