Re: Feedback about the cdd-dev package and more...
|--==> Andreas Tille writes:
AT> 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.
AT> Well, your arguing is very interesting, but:
AT> - You should have discussed this here.
AT> - It would be a good idea document it here.
AT> - You will have trouble to convince others if you stay that silent
AT> (I assume it is your goal to establish your system for other
AT> CDDs as well.)
Yes it's one of my wishes to have this famous CDD infrastructure, but
at the same way I don't have any really convincing solution at
hand. Thus I keep experimenting following the paradigm "First Do, Then
Document, Finally Automate".. I'm still at the "First Do" phase! ;)
>>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.
AT> Sounds clever and the *real* advantage of your idea instead of the
AT> "Personally I find more comfortable"
AT> 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.
AT> I do understand the problem of sub-grouping menu entries but I do not
AT> see any hint for a solution. Did I missed anything?
I'm not sure to understand your doubt, but my idea is to apply a tag
to each package which needs a different menu location than the regular
one.
E.g:
xmedcon: task::imaging, menu::Med/Imaging/Conversion
garlic: task::bio, menu::Med/Bio/Molecular
AT> BTW, the current implementation in cdd-dev for menus allows sub-menus
AT> 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.
AT> While I see both points (tags, directories) as interesting for certain
AT> reasons I might like to remind you all: We are talking about building
AT> a set of less than 100 meta packages with probably less than 100 dependency
AT> informations. I guess the number 100 is a quite safe estimation even
AT> for the future. So I ask you to make not a scientific problem of it
AT> and get something *working* which all people can agree with. I have
AT> no personal feelings about this and would be able to cope with both.
AT> But I really hope that we will find a common agreement in the *near*
AT> future and breaking the silence around all these single solutions *now*.
Well, ok we are talking about "little" things, but this doesn't mean
that we don't have to do things cleanly and beautifully..
IMO if we have not found a common agreement yet, is because still
there is no rocking solution.
>>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.
AT> Is this implemented anywhere in a comparable form to cdd-dev so that
AT> I'm able to hae a look at it / build my meta packages with it. Is
AT> there any example or whatever which draws this from abstraction to
AT> a code snipped + data set to look at?
Ok, I understand my previous post sounds rather "theoretical". I've
wrote some scripts which I consider quick and dirty hacks, but if you
like (some of) the idea(s) we can use them as a base.
Basically:
1) tag definition:
http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagvoc?op=file&rev=0&sc=0
2) tag application:
http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagpatch?op=file&rev=0&sc=0
3) script to generate the menu on the fly (goes in /etc/menu/demudi)
http://costa.wiggy.net/svn/demudi/demudi-menu/trunk/demudi-menu?op=file&rev=0&sc=0
4) script to generate tasksel entries:
http://costa.wiggy.net/svn/demudi/demudi-tasksel/trunk/demudi-tasks.desc?op=file&rev=0&sc=0
5) script to set some default tasksel actions:
http://costa.wiggy.net/svn/demudi/demudi-tasksel/trunk/standard?op=file&rev=0&sc=0
(this has been submitted to the BTS, #275303, and this list was in Cc:)
6) script to sort the packages list by relevance:
http://costa.wiggy.net/svn/demudi/demudi-debian-cd/trunk/demudi-tasksel?op=file&rev=0&sc=0
(it's used to distribute the packages over a cd set)
To check out the whole sources read here:
http://demudi.alioth.debian.org/wiki/DevelopCode
interesting packages are demudi-debtags, demudi-tasksel, demudi-menu,
demudi-debian-cd, demudi-debpartial-mirror, demudi-cfengine,
demudi-base-config.
>>and there will be a couple of scripts which will parse it (for example
AT> "Will be" or "is there" ?
Well, a mix of both actually, I've wrote kind of that, but it's far
from satisfactory.
Cheers,
Free
Reply to: