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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
