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