Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
On Sun, 2011-01-16 at 23:49 +0100, Lucas Nussbaum wrote:
> 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)
>
+1 from me on this.
> 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.
Agreed on this as well. As gems are added for more apps, libFOO-ruby
doesn't make nearly as much sense as ruby-FOO.
>
> 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.
>
I'd suggest that gem2deb be used initially, but that there be an effort
to do *as much as possible* in dh, so that one can simply bump upstream
revisions in the changelog of the packaging branch to accomodate new
upstreams, and bump the dh_ruby (or whatever its called) dependency
version if there is some new functionality necessary.
In this case, you'd just have the upstream branch and the debian branch.
Further, I hope to leverage gem2deb as the ruby backend for pkgme, which
seeks to have as close to zero changes between upstream source and
debian source package as possible. The better the dh component is, the
closer we can stay to that.
> 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.
This all makes sense. Maybe enable the test suite, but have it not fail
the build, so that one can see whether they passed or not.
I'd actually like to see the test suite run by default in the build, so
that it only gets disabled when it is really misbehaving, instead of
only being enabled when we think about it.
Reply to: