Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
On 29/01/11 at 08:03 -0300, Antonio Terceiro wrote:
> 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)
I think that we should go for this.
> *** 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})
And not for this.
Could you update the Wiki page? :-)
> 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*
Yes, true. Can you add it to the wiki page too?
L.
Reply to: