Hi, After quite some work together with Antonio Terceiro, we now have a mostly working gem2deb implementation. It can handle everything needed to package ruby applications and libraries inside Debian, and is much better than the current cdbs-based tool: - does almost everything automatically - uses dh7, much faster - easier to adapt to our needs - runs the test suite as part of the build
The source is available from https://github.com/ln/gem2deb To test, you need to: git clone git://github.com/ln/gem2deb.git cd gem2deb rake install then, cd to some temporary place, and do: gem fetch rdiscount # a native gem gem2deb rdiscount<TAB> or: gem fetch i18n # a pure ruby gem gem2deb i18n<TAB> This tool has two goals: - serve as a way for users to generate debs from gems locally - serve as a basis for packages provided in Debian However, there are several questions that need to be answered: 1) Do you want to move to that tool for Ruby packaging in Debian? (I'm assuming we do) 2) How should the packages be named? Since all the packages are going to be modified anyway, it's the perfect time to change the naming. I'd like to go with: + ruby-foo for pure ruby libs + ruby1.8-foo, ruby1.9.1-foo, and ruby-foo (common files) for native libs This is what python uses, and is much nicer than the current perl-inspired naming. 3) Should we change our packaging workflow? Using gem2deb, it would be quite easy to use git-buildpackage with: - an upstream branch - a gem2deb branch, providing the source package as generated by gem2deb - a debian branch, with the source package based on the gem2deb branch I believe that in most cases, we will only need marginal modifications from the gem2deb generated package, so this would be a good way to have an efficient workflow. 4) How should we migrate to the new packages? If we want to enable test suites during build (which would be a good thing), we need to be extremely careful about dependencies. Using the dependency info from the rubygems spec files, which is very far from being complete, I got the following graph when looking at the deps for the top 10 gems: http://blop.info/pub/rubydeps.pdf We could do a two-steps migration, first uploading the packages with the test suite disabled (so they can build fine) and then re-upload to enable the test suite when all the deps for it are available. - Lucas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
