[Pkg-ruby-extras-maintainers]

[Lucas Nussbaum]

On 24/11/05 at 10:45 +0100, Paul van Tilburg wrote:
> Hey,
> 
> On Wed, Nov 23, 2005 at 11:31:39PM +0000, Esteban Manchado Velázquez wrote:
> > On Wed, Nov 23, 2005 at 05:43:21PM +0100, Lucas Nussbaum wrote:
> > > [...]
> > > After thinking about it for a while, I came to the conclusion that we
> > > have to consider the user's point of view. There are two kinds of
> > > library users :
> > > - those only using software that relies on this library. Those don't
> > >   care about rdoc documentation, etc.
> > > - those developing software using this library. Those want as much help
> > >   as possible.
> > 
> >     Agreed. In fact, I consider this pretty important.
> 
> Indeed.
> 
> > > Therefore, I think ruby libraries should be packaged using two binary
> > > packages :
> > > - libxxxxx-ruby1.8: contains only /usr/lib/ruby/1.8/xxxx/* and the
> > > copyright/changelog stuff.
> > > - libxxxxx-ruby1.8-dev: contains examples, unit tests, rdoc
> > >   documentation, ri documentation.
> > 
> >     It's OK with me as long as all the stuff we decide to include in the -dev
> > package is really much bigger than the library itself.
> 
> Agreed.
> 
> >     Just one comment: wouldn't it be better having all the dev files
> > documentation in a version independent package, like libxxxxx-ruby-dev
> > (instead of libxxxxx-ruby1.8-dev)?
> 
> I think this is better too.  The dummy -ruby package is meant for the
> developer and so is the -ruby-doc package.  Besides that, the
> documentation isn't Ruby version dependent (in AFAIK all cases).

As said in my other mail, examples are ruby-version-dependant if they
include a shebang.

> > > About unit tests: it would be great to have a common architecture to
> > > deal with our unit tests. This way, one could run a script on a regular
> > > basis to check that all his installed packages still work correctly.
> > 
> >     I'm not sure I like this. I would prefer using the Ubuntu proposal (or
> > something similar) for package testing, and somehow plug the own library unit
> > tests into the distribution package framework. After all, the package
> > maintainer is basically who needs/is interested in package testing...
> 
> Yes, the unit tests need to be ran while packaging.  If unit tests are
> available for a library then this is great for the "package testing
> before upload".  I don't think a user/developer is going to rerun the
> tests to find the same results as the maintainer has.

This requires manual copying of the test scripts to the debian/tests dir
by the maintainer. This is error-prone, etc. The Ubuntu proposal is
flexible enough to allow to store tests in a -dev package. Also, another
reason for not storing tests in the source package is that the Ubuntu
proposal is not implemented yet.

I think test scripts often can be useful as documentation, especially
when example scripts are not provided.

Also, I personally would like to be able to run the tests on all ruby
packages on a regular basis. The fact that the package works at build
time doesn't mean that it will continue to work. For example, when rake
0.6.0-1 was uploaded, it was working just fine. But when ruby 1.8.3 was
uploaded, a change in fileutils broke rake (see bug #336937). If rake
came with a test suite, and if somebody had been running it regularly,
this would have been easily picked up.
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |