gem package naming (was Re: [GitHub] Formatting fixed [ln/gem2deb GH-19])
On 10/04/11 15:12, Lucas Nussbaum wrote:
On 10/04/11 at 10:42 +0100, David Greaves wrote:
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?
Yes.
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.
Agreed, it makes no sense whatsoever; it's a gem2deb option. I have no idea why
I put that there - I just wanted a 'disable this' mechanism.
Nice. Are you interested in maintaining some of them in Debian, by
contributing proper Debian source packages to the team?
That sounds like a goal.
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.
That makes complete sense to me as a designer.
However I'm not sure how well it promotes the 'similarity to gem'. It certainly
feels like it will become problematic.
I understand that http://rubygems.org is the canonical source of gem naming so
although it leads to one or two 'ugly' package names (like ruby-ruby-prof and
ruby-yajl-ruby) it also makes it 100% predictable to go from gem->deb which
helps both when packaging and when looking for a package when I've been told
which gem to use.
A quick look [1] shows:
http://rubygems.org/gems/mysql
http://rubygems.org/gems/ruby-mysql
http://rubygems.org/gems/units
http://rubygems.org/gems/ruby-units
So whilst ruby-<require name> makes sense, ruby-<gem name> is only slightly less
sensible and seems to offer significant non-technical benefits at the expense of
some aesthetics in package names.
PS A quick look in the archives didn't highlight this issue.
David
[1]
http://rubygems.org/search?utf8=%E2%9C%93&query=ruby-
http://rubygems.org/search?utf8=%E2%9C%93&query=-ruby
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
Reply to: