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