Clint Byrum escreveu isso aí:
> > I've started drafting some requirements for dh-make-ruby at the wiki:
> > http://wiki.debian.org/Teams/Ruby/dh-make-ruby
> >
>
> Reading through these, the only requirements dh_rubygems / dh-make-gem
> satisfy right now are:
>
> * use information to fil out debian/control
>
> * convert from gem to tar.gz (but does not use gem2tgz)
>
> * create packages that build correctly out of the box (correctly
> is a pretty wide open term though)
>
> To address some of the other points in that document
>
> * how to handle dependencies? - having already gone through both
> approaches while tinkering on dh-make-gem and dh_rubygems I think
> generating substvars is the right way to go. It makes the control
> file less volatile. dh_rubygems currently provides a --ignore-dep=X
> to allow you to specify a different debian package in the control
> file if it satisfies the ruby dep (though it might make sense to
> start doing Provides for these).
In this case handling dependencies is done during the build, then.
> * how to handle build-dependencies? - The "developer" dependencies
> in the gemspec MIGHT be useful here, but this is where my knowledge
> of how rubygems is actually used becomes limited.
My problem with this dependencies issue is that in the case we want to
run the package's automated tests as part of the build, in most cases
the runtime dependencies and the build dependencies will have a pretty
large overlap, and it would be ackward to generate pretty much the same
list with one being done when writing the source package, and the other
during build time.
OTOH, this seems to be exactly what Perl packagers do: I've just
checked some random perl package and Build-Depends: seems to contain all
the dependencies declared in its Makefile.PL, while the Depends: field
of the binary package contains ${perl:Depends} instead.
--
Antonio Terceiro <terceiro@softwarelivre.org>
http://softwarelivre.org/terceiro
Attachment:
signature.asc
Description: Digital signature