Hi, Thanks for this initial work.
On 26/04/11 at 08:38 +0200, Vincent Fourmond wrote: > Hello all ! > > On Tue, Apr 19, 2011 at 10:33 AM, Lucas Nussbaum > <lu...@lucas-nussbaum.net> wrote: > >> > What you are asking for is not a policy, it's a howto. > >> > >> I'm asking for both. > >> > >> I think the policy should be a docbook-like document (like the > >> Policy), while the howto probably should be a wiki page. > > > > I'm not too interested in working on paperwork, but if you are > > interested, I strongly encourage you to lead that work :) > > > >> What about making the Debian Ruby (sub) Policy part of the gem2deb > >> package ? > > > > Yes, why not. > > Good. I've written a first draft of a Ruby policy, which is > basically my interpretation of the whole gem2deb philosophy. I > encourage everyone to read it and point me where you think I have > misunderstood (on this list) or correct it themselves. > > The document is almost complete in the sense that I think I have > covered most of the requirements. A big exception though: I haven't > addressed at all the requirements for Ruby interpreters, which I think > should be part of the policy. > > The document is located in the gem2deb git repository. Could you make it a separate package? It sounds strange to first say that the gem2deb documentation cannot be considered a policy, and then to put the tentative ruby policy in the gem2deb package. > It is a > docbook document, which is fairly easy to read/write. Install the > package docbook-utils to convert to other formats (PDF, HTML, etc...). Could you provide a makefile? Some quick comments: > <para> > All binary packages that contains Ruby code &must; have a > package name in the form <literal>ruby-</literal>&pkg;, > where &pkg; is left to the choice of the packager. No, be more specific. Usually, it should be what you "require", or the gem name. > However, > packagers &may; ignore this rule in the following cases: > <itemizedlist> > <listitem> > <para> > ruby interpreters; > </para> > </listitem> > > <listitem> > <para> > programs; > </para> > </listitem> I prefer the wording from RubyInWheezy. + give examples > <listitem> > <para> > packages providing ruby code to be use specifically as > plugins for a given program, and that have no use > outside of this program. > </para> > </listitem> example? > </itemizedlist> > The source package name &should; match the name of package > that holds the code. the name of the main binary package? > </para> > <para> > In the case of software previoulsy relased with the old > package name policy > (<literal>lib-</literal>&pkg;<literal>-ruby</literal> and > versioned variants thereof), packagers &should; provide > transition packages with the old names depending on the new > package. > </para> > </sect2> This is a must, I think > <sect2> > <title>Supported Ruby implementations</title> > <para> > Packages &should; support as many different implementations > of Ruby as is possible. Reasons why this is not done > &should; be documented visibly, such as in the > <filename>README.Debian</filename> file. I prefer to document that in the changelog. > Packages &must; list the versions of Ruby supported in the > source package using the <literal>XS-Ruby-Versions</literal> > statement in <filename>debian/control</filename>. This > statement &must; be a space-separated list of one or more of > <literal>ruby1.8</literal>, <literal>ruby1.9</literal> or > <literal>all</literal> (the latter meaning all the supported > Ruby versions). Wrong, it's ruby1.9.1 > </para> > <para> > All files for the different implementations &must; be > shipped inside a single binary package. This binary package > &must; have a <literal>XB-Ruby-Versions</literal> statement > containing the space-separated list of Ruby implementations > supported by the binary package, with fields identical to > those for the source package, excepted that > <literal>all</literal> cannot be used: the full list &must; > be listed explicitly. > </para> > </sect2> > <sect2> > <title>Installation paths</title> > <para> > Pure ruby code (ie ruby files) &must; be installed under > <filename>/usr/lib/ruby/vendor_ruby</filename>. > </para> > <para> > Compiled extensions &must; be installed in the > <literal>'vendorarchdir'</literal> path. > </para> > </sect2> > > <sect2> > <title>Dependencies</title> > <para> > All package &must; depend either on <literal>ruby1.8 | > ruby-interpreter</literal> if the package supports all > implementations of Ruby or on the specific implementations > needed if that is not the case. > </para> > </sect2> > > <sect2> > <title>Documentation</title> > <para> > Packages &may; build a <literal>rdoc</literal> > documentation. Unless the documentation is really small, it > &should; be packaged in a separate binary package named > <literal>ruby-</literal>&pkg;<literal>-doc</literal>. > </para> > </sect2> > > <sect2> > <title>Rubygems</title> > <para> > Do we disallow the use of <literal>require > 'rubygems'</literal> by policy ? Yes > </sect1> > > <sect1 id="programs"> > <title>Ruby programs</title> s/programs/applications > <para> > Excepted for the package name, which does not have to comply > to any rules, Ruby programs &must; obey all rules that apply > to Ruby libraries (previous sections). In addition, they must > obey the following rules. > </para> > > <sect2> > <title>Shebang</title> > <para> > All the programs &must; have a <literal>#! > /usr/bin/ruby1.8</literal> shebang, unless they rely on > implementation specific libraries, in which case the shebang > should reflect these requirements. > </para> > </sect2> > </sect1> > > > </chapter> > > <chapter id="advices"> > <title>Advices to Ruby packagers</title> > > <para> > The contents of this chapter are not part of the Policy per > se. However, they should prove useful for developers wishing to > package Ruby-related packages. > </para> > > <para> > Nothing here yet. > </para> > > > </chapter> - Lucas -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426064939.ga6...@xanadu.blop.info
