Re: [Debian Wiki] Update of "Teams/Ruby/RubyInWheezy" by VincentFourmond
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
> <lucas@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
Reply to: