Re: Cooperating with the Gems Developers?
On Wed, Sep 21, 2005 at 11:18:06PM -0400, David Nusinow wrote:
> Hi all,
> Maybe we need to contact the gems developers on their own list and try
> and work out a way to fix the main issues we see. We can't force them to do
> any work, but if we present something concrete, we might be able to have a
> more productive discussion than what's going on between us and this Austin
> guy on ruby-core.
I am almost certain of that. It seems Austin has had some issues with
Debian somehow, maybe back in the time that the Debian/Ruby was much
much smaller. Anyhow, him projecting his troubles on us on the list
doesn't help us nor the gem ppl.
> It's pretty obvious that the code/packaging data can and should be
> separate, but we need to figure out a clean way of doing it. What we need
> to focus on is a design that we can build tools around. Fortunately, we
> have a lot of real-world know-how about how to separate packaging from
> code, given what we do :-)
Well, I saw something on the ruby-core list that is interesting though:
http://permalink.gmane.org/gmane.comp.lang.ruby.core/5196
and even:
http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-core/5882
I think I agree with all points both mails.
Ok, so a Gem ships source (hopefully not containing anything packaging
specific like require_gem) and metadata. If we ship our Debian-metadata
together with a Gem, we can unpack the gem and install it using a
gem-setup.rb or Rakefile, we are about done.
libfoo-ruby/
foo-1.0.0.gem
debian/
...
We can even add a tool to parse the gemspec and create a skeleton debian-dir
if we want. It's something that RPA could do a little bit, but as we all
know it never really evolved.
> I'm not going to have much time until early next week to work on this, but
> if no one else takes up the mantle, I'll start diving in to the gems spec
> and code and see what I can come up with. Either way, let's use this thread
> to hash out some sort of concrete proposal to take to them.
Let's :)
> Even if gems in its current form does go in to ruby's HEAD, we can work
> with the gems developers to fix it so it's not a problem in the future. If
> we cooperate, it will very likely make our lives as ruby packagers a lot
> easier in the long run.
Indeed.
Paul
--
Student @ Eindhoven | email: paulvt@debian.org
University of Technology, The Netherlands | JID: paul@luon.net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181
Reply to: