propsal: tasks

[Michal Moskal]

On Sat, Sep 21, 2002 at 08:40:23PM +0200, Tomasz Kłoczko wrote:
> On Sat, 21 Sep 2002, Michal Moskal wrote:
> [..]
> > > Tasks ide is IMHO stupid because it touches base level package
> > > dependencies. Installing grups packages for not skilled user can be
> > > performed by additional tools without additional dependencies.
> > > We are using now Group field only because it must be defined .. without 
> > > any additional consequeces so it can be explored for simplifyy some tasks 
> > > without any bad consequences. If you want regroup all packages/establish
> > > new hierarhy fill free.
> > 
> > As far as I understand...
> > 
> > Why using Group field for this purpouse is stupid?
> 
> Because adding/removing one package to group will do not require
> rebuilding any other resources.
> 
> > Let's think: I'm adding new cute SML compiler.  What Group shall I set?
> > I would said Development/Languages is good choice, it's a language. Now
> > let's think about poor user who is willing to install development
> > packages. He *is* going to install Development/Languages/* along with 5
> > SML compilers, 3 Java enviroments and so on.
> 
> First: stop this analize have current grouping. Current group hierarhy 
> only groups packages without (ones more) any useable rasonons.
> As I said: first you *must* prepare more useable Groups hierarhy.
> With lack useable hierarhy touching tasks idea only will be another 
> solutions for the same things where correct Group hierarhy can interact.
> 
> > So now you can say I should set Development/SML?
> 
> Don't ask me. Ask themeselve what this group can you bring as conseqence.

The main point is: it is not possible to assign group to every package
and make it work.  We simply have too much packages. (*)

> [..]
> > There are two basic problems with Group field: 1/ it does not include
> > *priority* of package,
> 
> Tasks idea also do not soves this ..

Of course it does: task-development-crucial, task-development-extra etc.

> > for example C compiler is much more crucial for development in *most*
> > cases, then MLkit, 2/ having in mind number of packages in PLD, too much
> > packages are going to get the same Group and too much dependencies is
> > going to be generated.
> 
> Tasks idea also do not soves this ..

See (*).

[snip]

Back to the point: personally I don't need tasks to be packages.
Packages could be usefull just for testing consitency.  What I'm going
to do is to simply move groups file to inst/pkg or somewhere where it will 
be cvs up'ed from time to time.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h