Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
On Mon, 2011-01-17 at 08:43 +0100, Lucas Nussbaum wrote:
> 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}.
If this is done in the dh_ code then those files can just be used as
additional stuff that the guessing missed.
> 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?
>
For runtime, pkgme is hands off and just dumps the appropriate substvars
in the Depends:/Recommends: fields.
For Build-Depends, (where pkgme really earns its money), each backend
has a command that is run to return the list. I'd like to see tight
integration with apt or even apt-file where possible, but at the very
least.. the python backend will know about python policy, and java one
java policy, with options to override these where necessary.
Reply to: