Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
On 18/01/11 at 12:26 -0600, Gunnar Wolf wrote:
> > 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).
Except that we have some libfoo-ruby that ship binaries (it was the case
for libgems-ruby, it's the case for librest-client-ruby). That causes
a lot of confusion for the users, too.
> > 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.
Why would it have to be uncoordinated?
So, we disagree on both (2) and (3). How do you suggest moving forward?
> > 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.
Sorry if it wasn't clear in my mail. The problem is that we are running
into a dependency loop:
package A requires B to run its test suite
package B requires A to run its test suite
which one should we package first, and how?
The only way to break the loop is to avoid running the test suite when
we first upload A, then upload B with the test suite enabled, then
upload A.
- Lucas
Reply to: