[Pkg-ruby-extras-maintainers] r134 - tools/ruby-pkg-tools/trunk

[Esteban Manchado Velázquez]

On Tue, Nov 15, 2005 at 11:16:54PM +0100, Paul van Tilburg wrote:
> Hey all,
> 
> On Tue, Nov 15, 2005 at 09:53:30PM +0000, Esteban Manchado Velázquez wrote:
> > On Tue, Nov 15, 2005 at 09:31:04AM +0100, Lucas Nussbaum wrote:
> > > [...]
> > > I haven't been following the recent changes closely, but I was wondering
> > > : how does ruby-pkg-tools work with sources packages with multiple
> > > binary packages, for example :
> > > - package with the library itself
> > > - package with small binaries related to the library (like -utils)
> > > - package with examples (like -examples)
> > > - package with docs generated with rdoc (like -doc)
> > 
> >     Basically the CDBS class (if it's that what you mean) doesn't "support"
> > (in the sense of aiding) none of that.
> 
> It should be possible though by installing to debian/tmp, and then using
> debhelper's <foo>.<dh tool> files to disperse the files over the package dirs.
> Kind of the same way dh_make distinguishes between lib (libfoo1 &
> libfoo-dev), single (foo) and multi (foo, foo-docs, foo-examples) libraries.

    Yes, it should be possible, but it seems to me like an over-engineered
solution. For Ruby modules, I guess _most_ packages are simply not going to be
splitted (or perhaps yes, if we decide so as a group, but we need to talk
about it first), so I would prefer letting the maintainer do those extra steps
by hand, and let the CDBS class take care of the common case. Of course, those
"extra steps" packages should be possible to package using the class _plus_
those extra steps... I mean, I _don't_ want a CDBS class that _only_ supports
simple packages.

> > > It would be great to package that kind of stuff with the cdbs.
> > 
> >     I'm not so sure. For most packages probably the documentation, examples,
> > etc. is going to be so small (in kbs) that it should be included in the main
> > package anyway.
> 
> That is kind of a problem.  For example, you have a lib bar.  You have
> libbar-ruby (dummy), libbar-ruby1.8, libbar-ruby1.9.  Where to stuff the
> documentation?  Twice (in -ruby1.8 and -ruby1.9)? In the _dummy_ package?

    In the not-so-dummy-anymore, I guess :-) I just checked, and some Python
packages do it that way (at least python*-{eyed3,gtk2,libxml2}).

> For documentation generation of some of the larger libs, having HTML,
> Ri docs, etc, this can sometimes be twice the size of the libs.
> So I'm not really comfortable with it.

    Yes, but, what size are we talking about? If it's under, say, 200k, I
would just put all the documentation in the package.

    I mean, what's the whole point of splitting something that _is_ bundled
upstream? I think the whole point is letting the user choose not to install
things he doesn't need, to save space, specially when they're installed as a
dependency, but when we're talking about a hundred kilobytes... it doesn't
seem worth it to me. And note that I'm not only talking about _our work_, but
also the complication and the burden we put onto our users, who will need to
know that they have to install another package to get documentation.

    Opinions? I think we have to talk about these things, to be able to write
the new Ruby policy.

    Regards,

-- 
Esteban Manchado Velázquez <zoso at debian.org>
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Help spread it through the Net in signatures, webpages, whatever!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20051118/2937b94c/attachment.pgp