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

Re: Feedback about the cdd-dev package and more...

On Thu, 2 Dec 2004, Free Ekanayaka wrote:

That was my idea to up to some months ago, see the structure outlined in:


near the half of the message.

However I have  to  say that now I  found  more comfortable to  manage
single files.

Thinking in terms of tags, a task shall be considered a tag applied to
a certain package.

For example I've wrote a little vocabulary for demudi task-tags:


which is contained in a single file, and then used the defined tags to
mark packages:


Personally I  find  more comfortable  having a  single  long list   of
packages,  alphabetically sorted  with tags   attached. This way  it's
straight  to check if  a package  is  present or  not,  which task  it
belongs to, move one package from one task to another etc.
Well, your arguing is very interesting, but:

  - You should have discussed this here.
  - It would be a good idea document it here.
  - You will have trouble to convince others if you stay that silent
    (I assume it is your goal to establish your system for other
     CDDs as well.)

Splitting  the tag  definitions     (the  vocabulary) from   the   tag
application also allow to insert package specific information.

For example I've add a "relevance" tag which is used to distribute the
packages in CD collection (mycdd-CD1, mycdd-CD2, etc). This way if you
want a minimal system  you just use CD1,  otherwise  you can get  more
Sounds clever and the *real* advantage of your idea instead of the
   "Personally I  find  more comfortable"
argument which is not very catchy for others.

Another  package specific information  it's  menu entry. We  can add a
"menu" tag to specify the location of a package in the menu tree. Note
that the mere  information of which task the  package belongs  to it's
not sufficient for  this, unless you  are happy with 1-level deep menu
trees or you introduces sub-tasks, sub-sub-tasks etc.
I do understand the problem of sub-grouping menu entries but I do not
see any hint for a solution.  Did I missed anything?
BTW, the current implementation in cdd-dev for menus allows sub-menus
exactly in the same way like any valid menu entry does allow this.

Moreover this way you preserve full modularity. That means if you want
to distribute  the task information in   different directories you can
still do it, a script can collect them together. On  the other hand if
you force a directory based approach some people (me  :)) may not like
While I see both points (tags, directories) as interesting for certain
reasons I might like to remind you all: We are talking about building
a set of less than 100 meta packages with probably less than 100 dependency
informations.  I guess the number 100 is a quite safe estimation even
for the future.  So I ask you to make not a scientific problem of it
and get something *working* which all people can agree with.  I have
no personal feelings about this and would be able to cope with both.
But I really hope that we will find a common agreement in the *near*
future and breaking the silence around all these single solutions *now*.

So  my proposal is to   use a tag oriented   approach. We just have to
define two formats:

1) how to define a tag
2) hot to apply a tag

these  are different   type  of  data which  shall  go   in  different
files. The number and hierarchy of such files is left at your taste.

Then the semantics  of a  certain tag (e.g.  task, menu,  priority) is
obviously defined by the scripts which parse the data files.
Is this implemented anywhere in a comparable form to cdd-dev so that
I'm able to hae a look at it / build my meta packages with it.  Is
there any example or whatever which draws this from abstraction to
a code snipped + data set to look at?

and there will be a couple of scripts which will parse it (for example
"Will be" or "is there" ?

Kind regards



Reply to: