[Pkg-ruby-extras-maintainers] Re: RubyGems in Ruby HEAD

[Hugh Sasse]

I don't know if I can post to all those lists, but I'll leave them
in in case it works....
On Wed, 21 Sep 2005, Paul van Tilburg wrote:

> Hi all,
>
> This reply is in the name of the Debian/Ruby Extras team.  When I write
> "we", I mean this group.
>
         [difficulties for repackagers]
>
> But it is our most important worry!  As Debian developer this would
> increase my amount of work for packaging _and_ maintaining each Ruby
> library/app.  Although this trend is more related to RubyGems popularity
> gain than the actual merge.

It seems to me that rubygems is going some of the way towards making
this easier:- gem help unpack gives

Usage: gem unpack GEMNAME [options]

         [...]

   Arguments:
     GEMNAME       Name of the gem to unpack

   Summary:
     Unpack an installed gem to the current directory

         [...]

What could be added that would facilitate creating package/rpm/???
for those who need to?  Given that we are discussing a TODO list at
the moment...

>>> To state it simply, it is often more difficult to package something
>>> released in .gem format than in an equivalent tarball + setup.rb. I
         [...]
>
> Indeed.  Note that this is partly due to a different point of view.  For
> Debian we package the libs and apps ourselves.  I hate to say it but
> there is almost no need for RubyGems in our case, whereas it is very

Except that rubyists expect things to work cross platform.  So how
can we add things to make it easier?

>
>>> * in general, problems due to the new directory layout
>>
>
>>> Each of these items means additional work when packaging a .gem: the
>>> source code must be patched before the actual repackaging work can be

Is there a limited set of things that you need to patch to do this?
Presumably it would then be possible to integrate this into the gem
command....  Rather like $ patch < boilerplate;
         [...]
>>
>
>
>> Those solutions may involve changes that can only happen when RubyGems
>> is incorporated in Ruby, but let's be realistic here.  If the RubyGems
>> developers aren't involved in repackaging efforts, those issues are
>> going to end up being low on their priority efforts unless someone
>> comes to them with concrete problems *and suggestions for solutions*.
>
> Ok.  Some concrete stuff then.
> * Upstream should only have to create a spec file, not change stuff in
>  the code, let 'require "foo"' stay 'require "foo"'.

You can get the gemspec out now.  I'm not familiar enough with
Debian to know what more info you'd need added to it, but that
seems, from my limited understanding, to be a good place to store
this info.

> * Create some generizable installer, maybe assist with Package[2] or
>  come up with something better, definitely useful to have a
>  distutils[1]-alike system in Ruby Core IMO.

I think this is a big project:  I know of ZIP, tar.gz files, Sun
package files, RPMs, and it seems no-one has found the be all and
end all of installers.  This problem needs to be bounded more, I
think.  If we are aiming for 1.8.4 anyway.

> Paul van Tilburg

         Hugh