Re: [Debian Wiki] Update of "Teams/Ruby/RubyInWheezy" by VincentFourmond
Hello,
On 19/04/11 07:10, Lucas Nussbaum wrote:
>> On 18/04/11 23:17, Lucas Nussbaum wrote:
>>> on rewriting the Debian ruby policy: I don't think that a policy is
>>> necessary if we standardize on gem2deb. The RubyInWheezy wiki page is a
>>> de-facto documentation of how ruby packaging should be done.
>>
>> No. For one, the X[SB]-Ruby-* fields are not mentioned, while they are
>> definitely important. As you have mentioned in another email, I missed
>> one field... simply because there no way to know it is needed !
>
> Strictly speaking, there is. You got an warning that you ignored:
> dpkg-gencontrol: warning: package ruby-net-scp: unused substitution
> variable ${ruby:Versions}
Sure, that just told me a generated variable was not used. As to how
to use it, this is another story ;-)...
>> Hmmm... That is the way you would do it, but there should be other
>> ways to do so. Do you think packagers of libraries that provide Ruby
>> bindings, but also python, perl and Java binding will want to restart
>> their packaging from scratch ? Having a well-documented path from old to
>> new including all the fields necessary and all the caveats is necessary
>> if you want the transition to happen.
>>
>> A template by dh-make-ruby isn't a policy.
>
> gem2deb provides you with a fairly complete starting point. To package
> something that can't be packaged by gem2deb alone, I would try to do the
> packaging with gem2deb, and then integrate the resulting bits into
> the existing package.
That's what you would do. You can't expect that everyone will want to
do it this way. No one wants to lose time starting packaging from
scratch. I think that transitioning to the new policy is something
necessary for Wheezy, and I'm grateful you started it. However, asking
every maintainer of Ruby packages to just "(re)start from scratch" isn't
going to work. This is just going to get people to simply stop
cooperating, just as you almost did with me :-)...
> What you are asking for is not a policy, it's a howto.
I'm asking for both.
First, a real authoritative policy document, in the spirit of the
Policy (with MUST and SHOULD where necessary ;-)... We could take
inspiration in the Java policy, for instance (I'm quite familiar with
that one). It would state:
* what is the package naming scheme
* where arch-all files should go
* where arch-any files should go
* which extra fields are needed in debian/control
* that a single package should contain binaries built for all ruby
versions it supports
* whether a package should build rdoc documentation, where it should
be located, whether or not ri should be supported, how it should
integrate, etc...
* whichever else requirements I can't come up with at this point
It would be a document to point at to others to say: your package
doesn't comply with the Debian Ruby policy, for this and that reason. It
would be something to post a link to in dda once the transition is
almost finished for pkg-ruby-extra and we want to other ones to join in too.
It should also list the things needed for any package to comply with
the Debian Ruby policy, regardless of whether the maintainer wants to
use gem2deb or not. I don't say we shouldn't try to convince maintainers
to use gem2deb, I just say we can't expect them to do so. The policy is
about how the final packages should look like, not which tools are used
for that purpose.
It would also be a document to be used to write lintian tags. Few
ideas come to my mind:
* ruby-library-but-no-ruby-version (for missing fields)
* ruby-files-in-system-dir (for stuff not in vendor/)
* ruby-library-starts-with-lib (to detect packages named libstuff-ruby
that are not transition packages)
* ruby-files-in-separated-packages (if files for different ruby
versions come in different packages from the same source)
...
> I agree that a
> step-by-step howto is missing, but it would be easier if someone else
> than me would write it after discussing the main points on the list (I'm
> of course fine with reviewing it).
Then, a how-to should be necessary, and should come naturally from the
policy document and the current packaging practices. It should include
the "gem2deb" from scratch, but also other approaches. "There's more
than one way to do it" !
I'm ready to participate in writing both, and potentially implement
the lintian tags too (I'm into subpolicy enforcement those days).
I think the policy should be a docbook-like document (like the
Policy), while the howto probably should be a wiki page.
What about making the Debian Ruby (sub) Policy part of the gem2deb
package ?
Then it could be possible as well to change the rub-pkg-tools cdbs
classes to either use dh_ruby or just "do the right thing". This will
greatly facilitate the transition: if people just have to change a bit
the control file but leave the build system as before, the transition
will go very smoothly. Then again, when I get more background on this, I
may want to dig into this.
I hope everything is clear.
Cheers,
Vincent
--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
His followers called him Mahasamatman and said he was a god. He
preferred to drop the Maha- and the -atman, however, and called
himself Sam.
-- Roger Zelazny, Lord of Light
Vincent, not listening to anything for now
Reply to: