Re: [DRE-maint] Rubygems

[Lucas Nussbaum]

(Added a Cc on debian-ruby@..., some interested people
might not be subscribed to pkg-ruby-maintainers)

Hi,

First, thank you for contacting us on that topic.

On 28/07/09 at 00:56 -0700, Yehuda Katz wrote:

> Hey guys,
> I recently read your position on Rubygems. I think we can probably find a
> way to solve the problem if we can get some help from Debian.
>
> It seems to me like you have the following problems:
>
> 1) People have libraries that rely on Rubygems. I agree with this issue:
> http://yehudakatz.com/2009/07/24/rubygems-good-practice/
>
> 2) You want a simple way to install packages without needing the full
> rubygems. To be honest, while you can appeal to the community to provide
> setup.rb, it would in fact be easier for us to provide you with a tiny
> subset of rubygems that can help you extract the installation information
> from the gem specification. You can then find the bin directories, as well
> as instructions for installing any binary gems. This will enable you to
> install the parts of the gem where you want, and make it trivial to make
> debian packages from rubygems. I would be willing to write something that
> could serve as the base for a Rubygems=>Debian package converter if one does
> not already exist.

The point of setup.rb is that it enforces a layout that is sane. Of
course, the same could be achieved by looking into the gem specification
to extract the relevant info, as you suggested. I'm not very familiar
with rubygems, but I have the impression that this solution might not
apply to all current gems: it will still require a special organization
of the files inside the gem to work. Can you give an example of the
information from the gem spec that we will be able to use?

> 3) Rubygems binaries have shebang lines that don't work on Debian or none at
> all. This is because Rubygems creates a wrapper file that points directly at
> the binary with the appropriate shebang. A rubygems=>deb converter could use
> the same technique and then stash the binary anywhere it wished. It could
> also copy the contents of the file out and replace or add the appropriate
> shebang. I'd note that /usr/bin/env ruby does not work on Windows and is
> therefore not considered a general purpose solution.

That problem is really not a severe problem (contrary to (1) and (2)).
Also, in the future, we might push (inside Debian) for a change from
/usr/bin/env ruby to /usr/bin/ruby1.{8,9,9.1}, so that it is written in
stone that one application wants to use a specific ruby version (and was
not tested/would not work with another ruby version).

> I understand that in a perfect world the Ruby community would conform with
> Debian's desires here. In practice though, I think we can work toward a
> solution that works for both communities with minimal fuss. I'm also
> probably not the first person who's attempted this dialog. Some in the Ruby
> community have decided to effectively write off Debian but I'm not willing
> to do so.

Well, I tried to start this conversation some time ago, and then decided
to stay away from this topic as much as possible, since several
"poisonous people" in the Ruby community (like Austin Ziegler) totally
discouraged me from continuing.  But we can try again, of course.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Gunnar Wolf]

Lucas Nussbaum dijo [Tue, Jul 28, 2009 at 11:01:07AM +0200]:
> (Added a Cc on debian-ruby@..., some interested people
> might not be subscribed to pkg-ruby-maintainers)

(And following the list usage policy we have just been discussing, I
dropped pkg-ruby-maintainers ;-) )

> Hi,
>
> First, thank you for contacting us on that topic.

I must also thank you, Yehuda. We _do_ need to work closer to our
upstream community, and strongly welcome you!

> > 2) You want a simple way to install packages without needing the full
> > rubygems. To be honest, while you can appeal to the community to provide
> > setup.rb, it would in fact be easier for us to provide you with a tiny
> > subset of rubygems that can help you extract the installation information
> > from the gem specification. You can then find the bin directories, as well
> > as instructions for installing any binary gems. This will enable you to
> > install the parts of the gem where you want, and make it trivial to make
> > debian packages from rubygems. I would be willing to write something that
> > could serve as the base for a Rubygems=>Debian package converter if one does
> > not already exist.
>
> The point of setup.rb is that it enforces a layout that is sane. Of
> course, the same could be achieved by looking into the gem specification
> to extract the relevant info, as you suggested. I'm not very familiar
> with rubygems, but I have the impression that this solution might not
> apply to all current gems: it will still require a special organization
> of the files inside the gem to work. Can you give an example of the
> information from the gem spec that we will be able to use?

FWIW, in most cases what our group does is to drop a known-good
version of setup.rb in the build directory at build time, and it (most
often) works as it should. However, there are several examples where
setup.rb must be hand-helped to do the right thing (and even there, I
am not sure if my hand-helping is correct). As an example:

    http://svn.debian.org/wsvn/pkg-ruby-extras/trunk/libprawn-ruby/debian/rules

Disregard the portion where I discard a bunch of images (as they are
not DFSG-free) and ensure they stay discarded by comparing their MD5s
to my files'; what I am doing in this debian/rules file (which is the
instructions to build the Debian packages) is:

• In the clean and makebuilddir targets, I deal with ttfunk and pdf,
  modules developed by the same author but under separate
  repositories, which he explicitly requested me _not_ to ship as
  separate packages; fortunately, it is enough to drop a link from
  lib/ to ../vendor/ and setup.rb will do the right thing.

• Fonts and common files which do not really belong to either the 1.8
  or the 1.9 packages (and which would cause conflicts if
  simultaneously installed) are moved to a third package in which both
  depend: libprawn-ruby-common. This is ugly, but the best way I could
  work out.
 
  FWIW, after talking with Lucas during DebConf9, there is huge hope
  for simplification here, as we will most probably be moving to a
  model where Ruby revisions will not have to be specified as part of
  the binary package names... So things will be easier then :)

> > I understand that in a perfect world the Ruby community would conform with
> > Debian's desires here. In practice though, I think we can work toward a
> > solution that works for both communities with minimal fuss. I'm also
> > probably not the first person who's attempted this dialog. Some in the Ruby
> > community have decided to effectively write off Debian but I'm not willing
> > to do so.
>
> Well, I tried to start this conversation some time ago, and then decided
> to stay away from this topic as much as possible, since several
> "poisonous people" in the Ruby community (like Austin Ziegler) totally
> discouraged me from continuing.  But we can try again, of course.

Yes, same experience over here, although I am more active among
Railsers and Lucas is a straight Rubyist. I have voiced some times the
needs we have¹, and got all kinds of results from the Ruby community -
including some very positive collaboration (such as the DebGem one²).

¹ http://gwolf.org/blog/its-just-different-mindset-not-necessarily-sane-one-though
  http://gwolf.org/blog/apt-get-and-gems-different-planets-right-it-must-not-be-war-worlds
  http://gwolf.org/blog/ruby-has-distribution-problem
  http://gwolf.org/debian%20rails

² http://gwolf.org/blog/debgem-its-way

--
Gunnar Wolf • gwolf@... • ([phone] / 1451-2244


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...