Re: Ruby packaging in wheezy: gem2deb, new policy, etc.

[Lucas Nussbaum <lucas@lucas-nussbaum.net>]

On 30/01/11 at 22:20 -0300, Antonio Terceiro wrote:
> Lucas Nussbaum escreveu isso aí:
> > > 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.
> [...]
> > Could you update the Wiki page? :-)

Note that this creates a dependency loop. I'm not sure if that's
considered bad or not.

> > > 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?
> 
> Updated. I also addressed Paul's concerns, by keeping a ruby-foo package
> even for purely-native packages. I am assuming we agree on the following
> principle:
> 
>   If you are targeting the default Ruby interpreter, installing ruby-foo
>   will always do what you expect.

Yes

> I still have one doubt, that's with the following statement: "libraries
> depend on '''ruby-foo'''". I am not sure what we mean with that, and we
> should probably think of all the possibilities:
> 
> pure-Ruby/pure-native/mixed package depends on 
> pure-Ruby/pure-native/mixed package
> 
> There are 9 combinations. Probably most of them can be handled
> uniformly, but some of them will bring trouble. Let's think about it.
> :)

I think that pure-native and mixed are the same. So we are down to 4
cases;)

pure depends on pure -> simple dep on ruby-foo
pure depends on native -> I would stay: simple-dep on ruby-foo. People
can install ruby1.9.1-foo foo if they want additional support

common package for native (ruby-foo) depends on pure -> simple, depend on ruby-foo
common package for native (ruby-foo) depends on native -> depend on ruby-foo

arch-specific package for native depends on pure -> simple, depend on ruby-foo
arch-specific package for native depends on native -> depend on
rubyXXX-foo

Would that work?

- Lucas