propsal: tasks

Tomasz Kłoczko kloczek at rudy.mif.pg.gda.pl
Sat Sep 21 20:40:23 CEST 2002


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.

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

Tasks idea also do not soves this ..

> 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 ..

> That's why we need some other way of helping users in package selection.

Still wrong ..
Now seems you acceps current Group hierarhy is incorreect/unuseable. As 
second yu musts accept as consequence: we need bettrer Groups hierarby 
(which in spe will groups packages in the same groups like tasks packages 
.. with one ecception: Groups hierarhy can have much more elements than
tasks-* number).

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek at rudy.mif.pg.gda.pl*



More information about the pld-devel-en mailing list