Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
Lucas Nussbaum dijo [Sun, Jan 16, 2011 at 11:49:24PM +0100]:
> 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:
Huge amouns of "thank you" and "congratulations" to you two!
I hope that besides your stated goals, this will smoothen our
interactions with the Ruby development community - As we will now be
able to use their files in their preferred distribution format.
Right now I am unable to test gem2deb, but am very interested in doing
so.
> 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.
Heh, not the first time you push that way :)
Still, I think the libfoo-ruby makes more sense when we are talking
about libraries. If an unexperienced user sees (picking a random
package of mine) a package called 'ruby-barby', with a slightly less
explicit description to what I have now (say, 'Barcode generation
tools'), he will probably install it and expect an application. Having
it called 'libbarby-ruby' makes it explicit it is a Ruby library. Of
course, the frameworks and applications should not follow this naming
scheme (as they are not just Ruby libraries).
> 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.
This could be efficient, but I'd like to keep having what we have now,
a single repository that carries all of the group's work, instead of
having a (very lightweight, yes, but uncoordinated) repository per
source package.
> 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.
Well, building a package should always (in a perfect world) include
running its tests. Of course, build dependencies can be huge. But I
don't think it is _that_ bad. And assuming we all build using
pbuilder/cowbuilder (right? No, I don't always - but it is a factor
that would push me to the right practices!), it would basically just
mean a minor inconvenience.
Reply to: