Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
On Sun, Jan 30, 2011 at 04:23:04PM +0100, Lucas Nussbaum wrote:
> On 29/01/11 at 08:03 -0300, Antonio Terceiro wrote:
> > 0) (native) "libs are named ruby1.8-foo, ruby1.9.1-foo, etc. and provide ruby-foo"
> > ----------------------------------------------------------------------------------
> > 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.
I agree partially.
In case (b) indeed, ruby-foo gives something that works, which is great.
But for case (a), IMO a far more often occurring case, it doesn't work.
Installing ruby-foo will make apt* return: what do you want?
> > *** 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.
Indeed. An additional object w.r.t. the one I gave above:
Provides semantics are nice if it is used to say something can fulfil
some depend demands. But if some program uses the foo library, it
doesn't help if you have libs saying they "fulfil" this depends, which
in essence is not true.
Paul
--
PhD Student @ Eindhoven | email: paulvt@debian.org
University of Technology, The Netherlands | JID: paul@luon.net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181
Reply to: