On 19/04/11 at 09:09 +0200, Vincent Fourmond wrote:
>
> 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 :-)...
Have you tried it? It takes 10 to 15 minutes to "restart from scratch for
existing packages".
> > 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.
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.
> 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 think that you should try to "restart from scratch" just for one
package, to see how it goes. a transition that doesn't require changes
in each package is not possible.
- Lucas