Re: [GitHub] Formatting fixed [ln/gem2deb GH-19]
On 10/04/11 at 10:42 +0100, David Greaves 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?
No.
gem2deb has two main use cases:
[A] generate Debian source packages for the pkg-ruby-extras, that, after
more work, can be uploaded to the Debian archive. To make this easy,
we need a tool that does as much as possible automatically, while
minimizing the risk of mistakes.
[B] generate Debian packages from gems for sysadmins that prefer to deploy
debs rather than gems. The quality level of those debs is expected to
be lower than the one from debs shipped in the Debian archive.
You propose to auto-generate the Depends: for the debs.
In use case [A], it doesn't make much of a difference. The debian
maintainer is expected to check the dependencies and fix them.
In use case [B], it means that, if the upstream developers are setting
dependencies that are useless (like, only for running test suites) or
too strict (regarding required versions), the generated package might
end up being uninstallable.
I don't have a strong opinion about this. We could try this, but I would
prefer if we kept a way to ignore the dependencies. So:
- by default, add a comment with the gem-provided dependencies, for
documentation.
- by default, generate (Build-)?Depends and (Build-)?Conflicts according
the gem-provided dependencies.
- provide an option (not an environment variable) to ignore the
versioning info provided by the gem
- provide an option that cause gem2deb to not generate the
Depends/Conflicts (the comment in kept)
Whould that work for you?
Addressing other points of your mail:
> 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")
That shouldn't be a DH_* environment variable.
> 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.
Nice. Are you interested in maintaining some of them in Debian, by
contributing proper Debian source packages to the team?
> Is ruby-extras going to support mixed gem/packaged solutions using
> something other that path ordering?
Local admins might want to install some gem2deb generated debs while not
having the whole dependency chain installed as gem2deb generated debs.
Of course, that's not something we want in the Debian archive, but if
gem2deb can support this use case...
> 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.
The current rule is (from
http://wiki.debian.org/Teams/Ruby/RubyInWheezy#Naming_of_ruby_packages):
- Binary packages must normally be named "ruby-foo". If the package is
mainly used as an application (not as a library), then it can be named
"foo". Known examples are rails, chef, rubygems, puppet.
- Source packages must have the same name as the "main" binary package.
(our infrastructure is better at handling this case)
foo should normally what you "require" in a Ruby script. So, for
yajl-ruby, it makes sense to call it ruby-yajl.
- Lucas
Reply to: