Re: [GitHub] Formatting fixed [ln/gem2deb GH-19]
Hi all
Quick intro: I'm new to debian-ruby and not an experienced ruby dev; OTOH I'm
using ruby quite a lot in some work I'm doing for MeeGo (I'm ensuring our tools
support Debian infra deployments). So, I'm really excited by this new deb2gem
approach and I'd like to help out.
The discussion below is in the gem2deb and ruby-<gemname> context.
(Moving the discussion to debian-ruby@. Context:
https://github.com/ln/gem2deb/pull/19)
I think that a compromise solution is needed. Could you provide a patch that
adds an option that, when enabled, auto-fills Build-Depends and Depends, and
when not enabled, adds the same information as a content before those fields?
Would that work for you?
Let me answer this first... sure, I'll do that if it ends up being your
preferred solution :)
Now some questions.
On 09/04/11 at 06:49 -0700, lbt wrote:
Hmm, so what's the point of gem2deb ? I inferred : "The best packaging
possible with the information available - minimise manual tweaking" So if
you put them in a comment you guarantee they're not used.and hence FTBFS in
a clean environment.
OTOH, the package will refuse to install if some libraries are manually
installed.
OK - so is the ruby-extras (?) policy to support a mixed environment? That means
that as a user, if I apt-get ruby-rails in a clean environment I somehow need to
know to get about 24 extra gems?
Clearly as a user I'm not going to go look in the comment in a debian/control
file... so maybe it should be at least a Recommends: ?
http://www.debian.org/doc/debian-policy/ch-relationships.html
As you improve the "just add ruby-" in front algorithm then less work is
required.
Oh, and they're not guessed :) .... the names are guessed but they
represent the upstream statement of dependencies.
... which might be wrong.
Sure - but isn't that the job of the packager? to debianise any dependencies
needed? Eg minitest build-depends on minitest and hoe build-depends on minitest
and hoe. That's just not going to work in a clean build environment and this is
one case where the upstream dependencies need tweaking.
Also, things like fcgi need to specify debian specific libs like libfcgi-dev for
native extensions... so gem2deb output is going to have to be verified manually.
Another case is that ruby-ruote-amqp has a hard dependency on =0.7.0 of
ruby-amqp since the api changed in 0.7.1 (!) but that means that 0.7.0-2 doesn't
meet that constraint. Debian has no < and would need a (manual?)
Conflicts: ruby-amqp (>= 0.7.1)
(OK, actually, maybe this is do-able algorithmically OTOH I am very sure that
there are gems out there with version = when it should be > or ranged)
Incidentally I added the DH_RUBY_NO_VERCHECK which is documented as:
# Set DH_RUBY_NO_VERCHECK to ignore gem version dependencies
(mmm, maybe that should be "ignore gem provided version dependencies")
I'm in the very early stages of packaging (hackily, for personal use) all the
gems needed for rails3 and so far about 90% seem to have the correct
dependencies - that significantly reduces the packaging burden.
So my point is, why not make gem2deb do more of the grunt work? If it gets it
right then that's great, if not *then* correct it.
Finally:
http://wiki.debian.org/Teams/Ruby/RubyInWheezy#gem2deb_as_the_preferred_packaging_tool_for_ruby_software
says "does almost everything automatically" :)
So... back to the Recommends: vs Depends:
Is ruby-extras going to support mixed gem/packaged solutions using something
other that path ordering?
I expected the approach to be that any apt-get installed gem would use Depends:
to pull in all the dependencies and if a developer wants to use local gems or
'sytem gem' (/usr/local/...) etc then it's up to them to override the
appropriate paths (in a well documented and supported way). Note that I wouldn't
expect /usr/local/*/*ruby* to be in the default path. As a distributor of a
packaged application I don't want rubygem installed gems getting into my app.
So... I propose keeping the patch as it is and
a) The .gem is right unless it's wrong - patch upstream if possible.
b) Use Depends: for dependencies
c) Define a hard rule on the gem->deb naming [1]
David
[1] eg what is yajl-ruby packaged as? gem2deb produces a ruby-yajl.deb today.
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
Reply to: