octave-maintainers
[Top][All Lists]
Advanced

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

Re: More octave-forge functions!!!


From: Søren Hauberg
Subject: Re: More octave-forge functions!!!
Date: Thu, 01 Jun 2006 22:48:47 +0200

tor, 01 06 2006 kl. 16:37 -0400, skrev John W. Eaton:
> On 29-May-2006, Soren Hauberg wrote:
> 
> | I really like the way the R people are doing things. They essentially
> | supply a base system, that only gives the most basic functionality. In
> | fact if you only install the base system, you won't be able to much
> | work. What the R people do next, is to have a rather large amount of
> | packages that depends on external libraries. To help new users the R
> | people have created a meta-package that depends on the recommended
> | packages.
> | 
> | Would this be an option for Octave?
> 
> Yes, we could do something similar.  But would it help?  I think a
> setup like that works well if there are many independent packages
> maintained independently.  Do we have that situation?  Do we have a
> lot of people who are willing and able to maintain all these separate
> packages, or would it just be more work to split things up and manage
> them as separate packages?  
I guess we don't really know if people are willing to maintain small
packages independently. This is the kind of thing you can only find out
by trying. So that's alot of work that very easily could be wasted if
nobody steps up to maintain the smaller packages.

> If not, then it seems simplest to just
> keep most "core" functions together in the same package instead of
> having a set of "core packages" that are all required to do real
> work.  From the point of view of the user, I don't see that it really
> matters, since most people will be installing all the core (or
> recommended) packages anyway.
The point I was trying to make, is that if the user has the choice to
not install subsets of "core" functionality, then it might not be a big
problem to introduce new dependencies. There is a tradeoff between
functionality and dependencies. Perhaps this problem is easier to handle
with smaller packages.

Fact is, that I don't really know what I'm talking about, and I haven't
formed an opinion on the matter yet. I'm just under the impression that
we try not to introduce to many dependencies, which might be a problem.

Soren



reply via email to

[Prev in Thread] Current Thread [Next in Thread]