On Wed, Jan 25, 2006 at 07:28:25PM +0100, Lucas Nussbaum wrote: > I'd like to raise again the subject of the naming of library packages. > I've read the python policy, which does sensible things, and wrote > > http://pkg-ruby-extras.alioth.debian.org/policy.html > > Could you please comment on what is proposed here ? First I want to comment that right now it is a bit messy in the repository. One can depend on ruby (>= 1.8), ruby (<< 1.9) or on ruby1.8 or libruby1.8 or ... and for the build-depends it is the same. It is not really clear what is The Way To Do It (tm). So this is probably why all Ruby packages in the archive currently do it all differently. My comments on Packaging Variants: - To depend on ruby or on librubyX.Y depends on what it is that your are packaging. Most Ruby libs will probably not need the interpreter but only the stdlib (thus libruby), the same holds for bindings. Apps will have #!/usr/bin/ruby or something similar in the code and will need the interpreter. - I am not sure if the variants you propose are a choice left to the maintainer or to us the policy-drafters (choose one and make it the policy). I rather have something that says that if a lib is something of kind A or B, you package it like variant (1) otherwise like variant (2). - I do not understand why there is a /usr/local/lib/site_ruby (also present in $LOAD_PATH) but no /usr/lib/ruby for "version independant" libs, this is IMO quite inconsistent. - I think that at the moment there is a huge amount of dummy packages just to depend on the only available -ruby1.8 one. I think we should stop this or start building our stuff for ruby1.9. My comments on Documentation and examples: - Now, the libfoo-ruby pkg has a pure dummy function and it would be strange for someone to expect documentation in a dumm package (if it is small), since almost all descriptions denote it to be just a dummy pkg. This will have to change. I agree though with the putting small docs in the "ex" dummy pkg. This is a good idea because the libfoo-ruby pkgs are meant for developers needing the libs. Apps that use the lib will depend on specific versions (libfoo-ruby1.8). This may depend a bit though on the outcome of the policy regards packaging variants. :) - It should me made clear that documentation should be available both in RI and HTML format. Some other issues I encountered/thought about: - Why is the lib structure not following the FHS? That is, using some of the interpretations. I have heard people commenting on that to me many times. All arch independant stuff should be in /usr/share. $LOAD_PATH would then become: /usr/local/share/site_ruby/1.8 /usr/local/lib/site_ruby/1.8 /usr/local/share/site_ruby /usr/share/ruby/1.8 /usr/lib/ruby/1.8 /usr/share/ruby . Note that there are no version-independent binary dirs (/usr/lib/ruby, /usr/local/lib/site_ruby/), since all shared libs are linked to some libruby. - Something is still missing about API changes (like what libcmdparse -> libcmdparse2 went through). Paul -- Student @ Eindhoven | email: paul@luon.net 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