On Sunday 16 January 2005 06:56 am, Kristof Bastiaensen wrote:
| On Sun, 16 Jan 2005 20:02:08 +0900, leon breedt wrote:
| > On Sun, 16 Jan 2005 19:51:19 +0900, Kristof Bastiaensen
| >
| > <kristof / vleeuwen.org> wrote:
| >> It does make sense, for example when the user wants a package that is
| >> written in Ruby, but doesn't want to program in Ruby itself.  In this
| >> case having all the ri-documentation would just fill-up space.
| >
| > What if the same user wants to run a Ruby package that requires a core
| > module to be present? Now they have to walk the dependency tree.
| > Space-saving vs. convenience. Which is more likely to annoy end-users?
|
| Apt-get should normally calculate the dependencies just fine (in a stable
| package).
|
| > A compromise could be to have a virtual Ruby package that declares the
| > correct dependencies to have the same modules as would be gotten by doing
| > a core install from source, at least you could opt out and delete the
| > virtual package and extraneous modules if you wanted to. I.e. instead of
| > apt-get'ing tens of packages:
| >
| > $ apt-get install ruby-core
| >
| > As I recall, it was mentioned that even this compromise was not deemed
| > acceptable by the Debian maintainers...although this is complete hearsay
| > as I heard it on IRC, so, take it with a tonne of salt.
|
| That looks like a good solution to me.  I have the impression that Debian
| maintainers like to create smaller packages, to prevent installing
| unnecessary files, so I don't see why they would find it unacceptable.

But try uninstalling just one of those small dependencies and apt-get wants to 
uninstall the whole kit-and-kaboodle. Argh... That's why I now have two 
versions of YAML on my machine :[

T.