Lucas Nussbaum escreveu isso aí:
> Hi,
>
> I have consolidated the discussion on
> http://wiki.debian.org/Teams/Ruby/RubyInWheezy
> Please review it carefully.
>
> Cosmetic changes and clarifications are welcomed directly on the wiki
> page.
>
> More fundamental changes should probably be discussed here first.
I found 2 points while reading that might be usefull to discuss:
0) (native) "libs are named ruby1.8-foo, ruby1.9.1-foo, etc. and provide ruby-foo"
----------------------------------------------------------------------------------
Our current approach is to make the "version independent" package depend on the
package for the default version. I just wanted to make sure: are we going to
change this? (I think it makes sense, anyway).
In the case we do change, then native packages won't have ruby-foo
anymore, only ruby1.8-foo and ruby1.9.1-foo. Currently gem2deb generates
all 3 packages for a native gem: ruby-foo, ruby1.8-foo and ruby1.9.1-foo
(ruby-foo does not depend on anything yet, but that should be fixed
unless ruby-foo is going away for native library packages).
But there is also the case where the package has both pure-ruby code
*and* a native library. Currently what dh_ruby does is to put the
pure-ruby code into ruby-foo (actually, in the first binary package
listed in debian/control) and the native libraries in
ruby{1.8,1.9.1}-foo:
terceiro@morere:/tmp/rdiscount-1.6.8/debian$ find ruby-rdiscount/ | grep vendor
ruby-rdiscount/usr/lib/ruby/vendor_ruby
ruby-rdiscount/usr/lib/ruby/vendor_ruby/rdiscount.rb
ruby-rdiscount/usr/lib/ruby/vendor_ruby/markdown.rb
terceiro@morere:/tmp/rdiscount-1.6.8/debian$ find ruby1.9.1-rdiscount/ | grep vendor
ruby1.9.1-rdiscount/usr/lib/ruby/vendor_ruby
ruby1.9.1-rdiscount/usr/lib/ruby/vendor_ruby/1.9.1
ruby1.9.1-rdiscount/usr/lib/ruby/vendor_ruby/1.9.1/i486-linux
ruby1.9.1-rdiscount/usr/lib/ruby/vendor_ruby/1.9.1/i486-linux/rdiscount.so
So we have 2 cases, which we could handle like this:
a) only native code:
Packages: ruby1.8-foo, ruby-1.9.1 etc
All of them must provide ruby-foo
b) both pure-ruby and native code
Packages:
ruby-foo - contains pure-ruby code
ruby1.8-foo - contains native code for ruby1.8
ruby1.9.1-foo - contains native code for ruby1.9.1
ruby1.8-foo and ruby1.9.1-foo (etc) depend on ruby-foo
ruby-foo depend on the version for the default interpreter (so that
installing ruby-foo will get you something that words)
*** OR ***
Packages: ruby1.8-foo, ruby1.9.1-foo
All of them provide ruby-foo
We duplicate the pure-ruby code in both packages (by installing to
.../vendor_ruby/${ruby_version})
I have the impression that b) is the most common case, anyway.
1) "we need to decide on a migration plan to avoid breaking the archive
for too long"
-----------------------------------------------------------------------
To avoid breaking everything, we could add
Provides: libfoo-ruby, libfoo-ruby1.8, libfoo-ruby1.9.1
for pure-ruby library packages, and
Provides: libfoo-ruby, libfoo-ruby${rubyversion}
for native library packages.
This way we don't break the existing dependencies on libfoo-ruby*
--
Antonio Terceiro <terceiro@softwarelivre.org>
http://softwarelivre.org/terceiro
Attachment:
signature.asc
Description: Digital signature