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
possible.
Regards,
Fumitoshi UKAI
Reply to: