Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
On 16/01/11 at 21:22 -0800, Clint Byrum wrote:
> > 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.
Sure. However, there's quite a lot of guessing going on in dh-make-ruby
to create debian/ruby-foo.{examples,docs,install}.
So, from time to time, it would be a good idea to re-run dh-make-ruby
and see if it picks up more things.
> 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.
How much knowledge will you have about other packages from inside pkgme?
Will you be able to guess dependencies based on the declarations in the
spec file?
> > 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.
True. I will implement that.
- Lucas
Reply to: