[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About the Ruby packages split: a concrete proposal

At Thu, 27 Jan 2005 17:32:43 +0100,
Paul van Tilburg wrote:

> On Thu, Jan 27, 2005 at 11:45:42PM +0900, Akira TAGOH wrote:
> > I think I understand the topic of this proposal. IMHO
> > changing the role of meta package here isn't good idea. and
> > I wonder what you mean by -core. also wonder if we really
> > need a lot of meta package for only Ruby. I disagree your
> > proposal then.
> Well, in only introduces two packages.  The role of package 'ruby' was
> changed because of what I hear most in the community that people expect
> 'apt-get install ruby' to provide them with the full Ruby interpreter +
> stdlib environment.
> 'ruby-core' was introduced analogous with x-window-system-core,
> gnome-core, etc.  People who know what they are doing can install the
> more lean version, mine preferred option anyway.
> And well...  'ruby-interpreter' is a natural consequence of the two
> things above.

If we take this option, I think we should change ruby1.8 as well,
otherwise it would be confusing. ruby means standards set of ruby,
whereas ruby1.8 means ruby1.8 interpreter only.

I prefer 'ruby1.8-bundle' or so for full set of ruby upstream package,
instead of changing meaning of 'ruby'.

> > However I like an idea of making a meta package like
> > ruby-stdlib. so another proposal from me to solve this
> > problem is:
> > 
> > - make a meta package like rubyX.Y-stdlib in rubyX.Y, which
> >   has all dependencies of the packages built from Ruby.  If
> >   you don't want to install some package in them, you can
> >   just install the packages you want from them so that you
> >   can see which packages are provided from Ruby now.
> > 
> > - make a meta package like ruby-stdlib in ruby-defaults,
> >   which has a dependency of rubyX.Y-stdlib according to the
> >   initial policy of ruby-defaults. I mean it works for
> >   providing the current stable version.
> I as well thought ruby-stdlib would be best, it is a solution too,
> although now I prefer the stair-like solution I'm trying out now.

So, the point is

 a) ruby1.8-stdlib depends lib*-ruby1.8 from ruby1.8 source 
			except libtcltk-ruby1.8, libtk-ruby1.8
    ruby-stdlib depends ruby1.8-stdlib

 b) ruby1.8-core is ruby1.8-stdlib + ruby1.8, irb1.8, rdoc1.8
    ruby-core depends ruby1.8-core

Supposed that we're trying to introduce new meta package for
novice's convenience, I feel ruby1.8-core would be better and
wonder ruby1.8-core depends/recommends ri1.8 as well and 
recommends/suggests ruby1.8-examples and ruby1.8-elisp.

I'd also like to add to ruby policy that it is not recommended that
debian package depends on ruby1.8-core.  Package maintainer should
know which package is required and declare dependency as small as 

Fumitoshi UKAI

Reply to: