On Oct 18, 2010, at 7:44 AM, Antonio Terceiro wrote: > Hi Clint, > > Clint Byrum escreveu isso aí: >> On Oct 17, 2010, at 9:20 AM, 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). >>> >> >> 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 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. > > I see that dh_rubygems generates the dependencies during build time, > like dh_perl. What would be the issue with new versions? >
Just mechanical changes are needed. Right now the only option I have is .gem -> source dir. I would like to have an option to work more like uupdate.. but with a .gem. >> 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. > > Yes, debigem is a very nice work. In special, reading the gemspec file > and generating proper debian/control and debian/copyright files is very > important for us, and if you agree it would be nice to turn parts of > debigem into dh-make-ruby. > I'd love for that to happen and will definitely devote some effort to supporting any such efforts. BTW, I shy'ed away from generating the copyright file because I think that always needs a bit of a manual review and requires some decision making by the maintainer. > I've started drafting some requirements for dh-make-ruby at the wiki: > http://wiki.debian.org/Teams/Ruby/dh-make-ruby > Reading through these, the only requirements dh_rubygems / dh-make-gem satisfy right now are: * use information to fil out debian/control * convert from gem to tar.gz (but does not use gem2tgz) * create packages that build correctly out of the box (correctly is a pretty wide open term though) To address some of the other points in that document * how to handle dependencies? - having already gone through both approaches while tinkering on dh-make-gem and dh_rubygems I think generating substvars is the right way to go. It makes the control file less volatile. dh_rubygems currently provides a --ignore-dep=X to allow you to specify a different debian package in the control file if it satisfies the ruby dep (though it might make sense to start doing Provides for these). * how to handle build-dependencies? - The "developer" dependencies in the gemspec MIGHT be useful here, but this is where my knowledge of how rubygems is actually used becomes limited. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
