Re: Building a Debian package out of a Rubygems' .gem file
Hi,
On 17/10/10 at 13:20 -0300, Antonio Terceiro wrote:
> Hi there,
>
> I've just published a post that provides some information on some stuff
> I've being working on, such as gem2tgz, and the newest addition, a
> debhelper buildsystem implementation that reproduces the behaviour of
> our current setup.rb CDBS rules, with some differencies.
>
> http://softwarelivre.org/terceiro/blog/building-a-debian-package-out-of-a-rubygems-.gem-file
>
> I would appreciate any feedback on that, and ideas on how to cope with
> the missing bits (there are plenty of them).
Thanks a lot for your work and for this clarifying blog post.
One thing that we should also develop a vision for is the way to deal
with test suites. It would be great to auto-test packages for the
various Ruby versions at build time. I'm not too familiar with the
various test frameworks in ruby those days, so I'm not the best person
to comment on it, but that should be investigated.
Commenting on the comments:
On 18/10/10 at 10:28 +0530, Deepak Tripathi wrote:
> 1) we can avoid first two steps using alioth's gemwatch so that
> packager
> should come to know that what to put in debian/watch file too :) .
I think that it's important to develop a set of tools that work the Unix
way (do only one thing, do it good, provide way to integrate with other
tools).
There are some libraries that aren't shipped as gems, there are some
that are not hosted on rubygems.org, etc. It's important to provide a
solution that works even in those cases.
> 2) we can have a example of CDBS too.
I think that the tendency in Debian is to move away from CDBS and switch
to Debhelper7. I'm not extremely happy about that, but if everybody else
is doing it, we should probably switch too. And I don't think that we
have the manpower to maintain two different helpers.
> 3) debian/source directory significance and quilt(native ) and quilt
I think that we should standardize on v3 (quilt) format for all our
packages (except the native ones, of course). It's important to minimize
the differences between the various packages, so we can spend our time
on real bugs rather than picky packaging issues.
On 17/10/10 at 23:00 -0700, Clint Byrum wrote:
> Antonio, I think we may have been doing some parallel work.
>
> My focus is on making it easy to go from gem -> .dsc with Debigem
>
> https://launchpad.net/debigem
I think that it's important to do:
.gem -> (.tgz + metadata) -> .dsc
to accomodate for all the use cases
> I just released a version which no longer uses 'gem install' to put
> the files down on the disk, but rather users setup.rb.
>
> My next challenge is in handling new versions gracefully by extracting
> the yaml spec file properly, as the program I wrote, dh_rubygems,
> tries to do the ruby dependencies based on the gemspec dependencies.
>
> Anyway, I hope its of some use and would be thrilled if you chose
> to lift some code from it for what you're doing. I find that most
> well written gems work without modification just by go dh-make-gem
> file.gem and then debuild'ing in the source dir.
>
> If you think my time would be better spent working on your tool, let
> me know, I would love to collaborate on this.
Do you see your tool as something that will be used by end users to
generate debs from gems, or by debian packagers to generate
archive-quality debian packages ?
I think that the Debian Perl way is the right way: have a dh-make-ruby
script that generates a clean source, using the gem metadata as a basis
for as many things as possible, and provide a way to update the debian
package from an updated upstream version.
Copying what they did also has the advantage of not confusing people
with two different workflows.
- Lucas
Reply to: