propsal: tasks

[Michal Moskal]

On Fri, Sep 20, 2002 at 09:00:37PM +0200, Tomasz Kłoczko wrote:
> On Fri, 20 Sep 2002, Michal Moskal wrote:
> 
> > There are special packages called 'tasks' in debian. Some time ago I
> > discuss this matter with Pawel Gajda. We come to conlusion that tasks
> > would be better as a way of selecting packages then existing groups
> > file. Reasons:
> > 
> > 1) they are more understandable by avarage developer then bizzare groups
> > file syntax
> > 2) they can be easly checked (if all required packages are available)
> > 3) they are not bound to bootdisks (they are fresh on ftp all the time)
> > 
> > There is a problem with MTA-like packages, where one can select one of
> > many possibilities but there are not so many of them so it can be
> > resolved with separate text file (like groups).
> > 
> > RFC.
> 
> 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? 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. So now you can say I should set
Development/SML? Then let's take Development/OCaml. All ocaml-* packages
should go there, including bindings for X11 or SQL libraries. So if I'm
going to install Development/OCaml/* then I'll get X11, Glade, some SQL
libraries and lots of other useless stuff installed.

There are two basic problems with Group field: 1/ it does not include
*priority* of package, 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.

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

After some thoughts I think that having task-* as package isn't as
important. Maybe they could be built and placed on ftp, but only for
checking (poldek -V). But simple command (like 
rpm -qRp task* |gzip> groups.gz) could be used to generate groups for
installer. Anyway they should have the same status as packages.dir.gz,
i.e. they should come with packages not installer.

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