On Tue, Nov 13, 2012 at 12:48 PM, Antonio Terceiro <[email protected]>wrote:
> Lucas Nussbaum escreveu: > > On 08/11/12 at 02:33 +0100, Antonio Terceiro wrote: > > > Lucas Nussbaum escreveu: > > > > > installing default gems: /tmp/r/lib/ruby/gems/2.0.0 (cache, > doc, gems, specifications) > > > > > bigdecimal 1.1.0 > > > > > io-console 0.3 > > > > > json 1.7.1 > > > > > minitest 3.4.0 > > > > > psych 1.3.4 > > > > > rake 0.9.2.2 > > > > > rdoc 3.9.4 > > > > > test-unit 2.0.0.0 > > > > > > > > Addressing that will be interesting ;) > > > > Maybe we could just drop those bundled gems and depend on our own > > > > packages. (I don't mean that we should 'cripple' ruby by removing > part > > > > of what is shipped by default -- I just mean that those gems should > come > > > > from the standalone packages rather than the bundled versions) > > > > > > We need to be careful to avoid circular dependencies there - those > > > packages would need to depend on a ruby interpreter, but the ruby 2.0 > > > interpreter would depend on them. > > > > Mmh, I've never been very clear on whether circular dependencies are > > actually that bad. In that case they would be pretty limited. > > Regardless of how we feel about circular (build) dependencies, I think > we should diverge as little as possible from upstream, i.e. letting the > interpreter package embed the gems it was design to, and allowing > standalone packages of those gems to override the pre-bundled gems - > just like it would work with outside of Debian. > Would It be bad to have the package broken up into ruby-minimal and the gems and then have a metapackage depend on the whole standard distribution? That way packages can depend on less than the standard distribution. (gem2deb wouldn't do this automatically) -- --- Shawn Landden
