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:
http://lists.debian.org/debian-custom/2004/04/msg00156.html
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:
http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagvoc?op=file&rev=0&sc=0
which is contained in a single file, and then used the defined tags to
mark packages:
http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagpatch?op=file&rev=0&sc=0
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
packages.
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
it.
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
Andreas.
--
http://fam-tille.de
Reply to: