Re: Ruby packaging in wheezy: gem2deb, new policy, etc.

[Clint Byrum <clint@ubuntu.com>]

On Tue, 2011-01-18 at 09:23 +0100, Lucas Nussbaum wrote:
> On 17/01/11 at 12:55 -0800, Clint Byrum wrote:
> > On Mon, 2011-01-17 at 19:26 +0100, Lucas Nussbaum wrote:
> > > On 17/01/11 at 09:43 -0800, Clint Byrum wrote:
> > > > On Mon, 2011-01-17 at 09:28 +0100, Lucas Nussbaum wrote:
> > > > > On 17/01/11 at 00:05 -0800, Clint Byrum wrote:
> > > > > > On Mon, 2011-01-17 at 08:43 +0100, Lucas Nussbaum wrote:
> > > > 
> > > > > > > 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.
> > > > > 
> > > > > I don't understand what you mean. Could you explain?
> > > > > 
> > > > 
> > > > Basically, instead of relying on dh_installdocs to put the things listed
> > > > in ruby-foo.docs into debian/ruby-foo/usr/share/doc, you would just have
> > > > dh_ruby put the known ruby documentation there.
> > > 
> > > But then, it would severely limit the possibilities for overrides, and
> > > we would end up basically reimplementing debhelper.
> > > 
> > 
> > I suppose it does get redundant with dh_installdocs. What if
> > dh-make-ruby just added a directory to the .docs file and then dh_ruby
> > will copy the docs into that directory?
> > 
> > As far as overrides, that seems rather simple to me.
> > 
> > dh_ruby --ignore-doc=x --ignore-file=y
> 
> That could work. But, I don't see any advantage compared to the current
> behaviour (have dh-make-ruby create the .docs file at src pkg generation
> time, and then use dh_installdocs at build time). The current behaviour
> has the advantage of using the standard way of controlling the
> installation of those files, and thus makes the learning curve for
> current Debian packagers easier.
> 

The advantage is minimizing package maintenance work after creating the
package.

If most of the dependency info, docs, etc can be determined from the
upstream source contents, which are already being used to build other
packaging formats, then by doing it in debhelper instead of in
dh-make-ruby, we lighten the load of the packager, as that is one less
step to take on upstream release, and less changes to review. We also
increase the accuracy of the resulting binary packages as they will pick
up important changes from upstream just by being built.