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).
> > 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.
> > About ri documentation: is there a debian package already generating
> > some of it, except the ri1.8 package itself ?
>
> What do you mean? Each package should generate its own documentation,
> right?
There were. In the libdbus-ruby upstream source there is a script for it,
I used it originally to do Rdoc RI and HTML generation for some package in
my CDBS class (now superseeded by Esteban's). But I removed it from all
my packages in favour of a generic tool for this, that is yet to be
created, see also (and edit/append):
http://pkg-ruby-extras.alioth.debian.org/cgi-bin/wiki/index.cgi?DocumentationGeneration
> > while generating XMPP4R's documentation :
> > [...]
>
> Wow. It's big indeed, and RI is more or less the same size, so it seems
> that if we include either RI or rdoc documentation (which seems like a good
> idea), the result is going to be _way_ bigger than the library.
I do not agree with either/or. RI usage is so much different than the
HTML. I use RI frequently to lookup a method, but the HTML much more
for comprehension of a library and seeing the bigger picture.
> If we drop the unit tests, I think I would prefer having the packages
> named libxxxxx-ruby-doc, instead of libxxxxx-ruby-dev.
>
> So, in short, I would vote for:
>
> 1) Generating RI documentation for the package.
Agreed (and HTML generation)
> 2) Not generating rdoc documentation (I'm not sure about this one, but
> seems redundant if we already have RI).
Maybe make the HTML generation optional for smaller libs, but
if one install the -doc package, one wants all the docs.
> 3) Not packaging unittests at all.
Agreed.
> 4) Having, for the foo library, libfoo-ruby, libfoo-ruby-doc (I prefer
> -doc to -dev) and libfoo-ruby1.8 (and
> libfoo-rubyOTHERSUPPORTEDRUBYVERSIONS).
Yes.
Greetings,
Paul
--
Student @ Eindhoven | email: paulvt@debian.org
University of Technology, The Netherlands | JID: paul@luon.net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181
Attachment:
signature.asc
Description: Digital signature