[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On 18/01/11 at 10:52 -0800, Clint Byrum wrote:
> 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.

Both ways to do it have merits. I prefer the currently implemented way
because it won't magically make changes to what we ship, without the
maintainer's intervention. Also, it sounds more like the Debian way.

However, we could have a mode where dh-make-ruby would auto-fill .docs,
.examples etc with what it finds. It wouldn't be good enough for
distribution-shipped packages, but would probably be enough for people
running gem2deb as a one-shot thing. Patch welcomed. ;)

- Lucas


Reply to: