|--==> Sergio Talens-Oliag writes: ST> [1 <text/plain; us-ascii (quoted-printable)>] ST> El Thu, Dec 02, 2004 at 01:29:25PM +0100, Free Ekanayaka va escriure: >>|--==> Sergio Talens-Oliag writes: ST> My current proposal is to put all files related to a 'task' inside a ST> directory; currently I have three different kind of inputs: >> >>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.
ST> Yes, it is quite similar, simply changing the suffix to a prefix (well, I've ST> suggested a directory instead, mainly to make things more readable). >>However I have to say that now I found more comfortable to manage >>single files. ST> Are you talking about a single file for multiple tasks? If that is the case ST> I don't see the advantage, but probably scripts to support splits and joins ST> can be written. >>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. ST> Well, that's only for the package selection list, and I have various ST> concerns about it: ST> 1. IMHO the tag system you are describing is less powerful than the proposed ST> pseudo-contol files, mainly because you are not adding extra information ST> that can be useful for other package selection mechanisms (for example we ST> can't express Recommends, Suggests or Conflicts for packages neither declare ST> relations between tasks), and, in any case, both files could be generated ST> from the tasks control files (or other format we agree on) I didn't think to any formal proof, but I guess they are semantically equivalent, it's mainly a design issue. For the record if you want to express package level Recommends, Suggests, Conflicts you *must* use the package control file (possibly contacting the maintainer), I think this goes without saying. It doesn't make any sense to me to declare such information on a different level. If you want to declare task level Suggests, Conflicts, Recommends I provided an example in my previous post, maybe it wasn't clear. You have the vocabulary file with the definition of the task tags: Tag: task::mytask1 Description: bla bla more bla bla Depends: task::mytask2 Suggests: task::mytask3 Conflicts: task::mytask4 ST> 2. The advantages of using one file are minimal if your reasons are only the ST> ones you describe; all the checks you are asking for can be done using very ST> simple scripts (in fact you could do it generating your current tagfiles, ST> but probably a query system would be better). Yes, that's correct. It's a matter of taste and comfort. Initially I had pseudo-control files split in different directories named as the task name. But while working (adding/remove packages) I realised that it would have been much more comfortable for me having a single, alphabetically ordered list of package names, with all the information attached (tasks the package belongs to, menu entries, relevance), e.g.: http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagpatch?op=file&rev=0&sc=0 That's only a matter of comfort, and it's definitely a personal view. ST> The main problem I see is that we aproach the problem in using two different ST> models: you think in terms of individual packages, while I think in terms of ST> tasks. I want to be able to work on tasks idependently and define relations ST> between them. Yes, but that's a thing you can do with my model too. Tasks are particular tags, and you declare relationships between tags. See above. Having a file (or multiple files if you prefer) with *only* the task tag declaration, and not the packages they are composed of has also the advantage that it's easier to read the task relationships: in case the tasks have lots of packages the distance of two Task: entries might be very long in terms of lines. ST> Think that my CDD model needs to support multiple Flavours of the CDD, so a ST> task has to be able to include the packages already present on other tasks ST> (posibly configuring it on a different way). Ok, if a task needs the packages of second task, just make it depends on it. That's a thing you can do with my model too. If you want a package to be present in two different task, just tag it accordingly: mypackage: task::mytask1, task::mytask2 >>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. ST> Yes, but this can also be done on the pseudo control file and later ST> translated... Yes but how do you define the relevance of a *package* (not a task). This is useful to distribute packages over a CD set, the most relevant packages first and the secondary ones later. You should be able to have a functional system with only the first CD, and use the second the third etc only if you really need more things. It's a feature that it's needed by A/DeMuDi for example. I think that with pseudo-control file you need something like: Task: mytask1 Description: bla bla Depends: pkg1 (relevance=10), pkg2 (relevance=6) which is fine for me, but if you need to add other package specific information, like the menu path, you have: Task: mytask1 Description: bla bla Depends: pkg1 (relevance=10, menu=Some/Custom/Path), pkg2 (relevance=6, menu=Some/Other/Path) Note that the menu entry and the relevance shall be also duplicated in case a package appears in more than one task. So why not having an alphabetically ordered list of packages containing package specific info? ST> maybe your idea is that we need to have a task index that ST> defines all of them in one place, that's no problem for me, in any case ST> almost all task systems will generate one form of this file and it can also ST> be used to declare the inter-task relationships. >>Note also that in the vocabulary: >> >>http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagvoc?op=file&rev=0&sc=0 >> >>there is a Relevance: stanza which has a different meaning than the >>"relevance tag". It applies to the task/tag as a whole rather than to >>a single package, and it's used to order the task list when displayed >>when you launch tasksel. ST> More metainformation, perfect... maybe the taskindex is a good place to put ST> all this. ST> Proposal changes: ST> - What about having one file that declares all the tasks and can be used ST> alone or splitted? ST> Using the current pseudo-contol syntax the idea is that each Task begins ST> when a Task: field appears and ends when another Task: field is found; if ST> the same Task appears more than once the information is appended to the ST> original Task. ST> The pseudo-control file can add an **Include:** field that is replaced by ST> the contents of a file (or all the files inside a directory, if the ST> include points to one). ST> To be able to support multiple preseed and postconfig schemes we can also ST> add tags to declare preseed and postconfig files (i.e. InstallerPressed:, ST> DebconfPressed: and PostconfScript: fields) for each Task. The idea is the ST> same, this information can be used to declare individual files or complete ST> directories, making it compatible with the current Debian-Edu model of one ST> file per task only by adding one or two lines to the pseudo-control file. ST> - And what about a 'flavours' file? besides the file that defines the tasks ST> we can also have an 'optional' file that defines flavours (if the CDD ST> needs them). Basically a flavour would be a list of *tasks* that should be ST> installed together and can be used to generate a menu for the second stage ST> of the debian-installer. >>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. ST> Well, as I've said the menu thing is something I have not studied, but I see ST> no problem in using whatever technique we need to add them, a tagfile seems ST> a very natural way of doing it. Of course the pseudo-control file can add ST> another field to declare what menu entries it is going to use (if we use ST> tagfiles we can point to a tagfile that declares all the task menu entries ST> or simply declare which tags are we going to use to build the menus). So when you want to add a package you have to add it both to the pseudo-control file (in the Depends: stanza of some task) and in the menu tag file, and if another information comes out in future in a third file an so on.. Isn't that clean. Am I missing something? >>So splitting tags definition and application makes sense to me. >> >>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. ST> Well, I've changed my proposal to allow anyone choose it's preferred layout: ST> one file vs. multiple files/directories. >>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. ST> Well, it's more or less the same thing, I still prefer the pseudo-control ST> format anyway, I believe is more powerful (maybe I'm wrong and both are ST> equal) and the conversion to your system should be trivial. >>Then the semantics of a certain tag (e.g. task, menu, priority) is >>obviously defined by the scripts which parse the data files. ST> And those are the things I want to define formally, using a set of well ST> documented Standard Fields and usages... the 'X-Field' mechanism allows ST> anybody to test extensions and propose it's inclusion on the standard ST> CDD format. >>As far as tag definition is concerned I'd I'd use the debtags format, >>which is basically identical to the one currently adopted by cdd-dev >>and described by Sergio. ST> Well, we can dicuss it further, but yes, your proposal is what I'm calling ST> all the time a pseudo-control file. >>However I'd distinguish two levels. ST> I don't really see the need to support *raw* tag definitions, from our point ST> of view everything has to be standarized, if the *raw* tag file is used by a ST> menu generator or other system the files can be included on the CDD definition ST> package as the presseds or the postconf sctipts are, but the package ST> selection list does not need to support them directly. The use of "raw" tag definition, is that a tag stanza at low level doesn't require particular fields. On the other hand, particular tags like task:: or menu:: do require particular fields. The raw definition is used by common parser that can be used by the scripts which actually implement the semantics of particular tags (task:: menu::). Cheers, Free
