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. Yes, it is quite similar, simply changing the suffix to a prefix (well, I've 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. Are you talking about a single file for multiple tasks? If that is the case I don't see the advantage, but probably scripts to support splits and joins 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. Well, that's only for the package selection list, and I have various concerns about it: 1. IMHO the tag system you are describing is less powerful than the proposed pseudo-contol files, mainly because you are not adding extra information that can be useful for other package selection mechanisms (for example we can't express Recommends, Suggests or Conflicts for packages neither declare relations between tasks), and, in any case, both files could be generated from the tasks control files (or other format we agree on) 2. The advantages of using one file are minimal if your reasons are only the ones you describe; all the checks you are asking for can be done using very simple scripts (in fact you could do it generating your current tagfiles, but probably a query system would be better). The main problem I see is that we aproach the problem in using two different models: you think in terms of individual packages, while I think in terms of tasks. I want to be able to work on tasks idependently and define relations between them. Think that my CDD model needs to support multiple Flavours of the CDD, so a task has to be able to include the packages already present on other tasks (posibly configuring it on a different way). > 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. Yes, but this can also be done on the pseudo control file and later translated... maybe your idea is that we need to have a task index that defines all of them in one place, that's no problem for me, in any case almost all task systems will generate one form of this file and it can also 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. More metainformation, perfect... maybe the taskindex is a good place to put all this. Proposal changes: - What about having one file that declares all the tasks and can be used alone or splitted? Using the current pseudo-contol syntax the idea is that each Task begins when a Task: field appears and ends when another Task: field is found; if the same Task appears more than once the information is appended to the original Task. The pseudo-control file can add an **Include:** field that is replaced by the contents of a file (or all the files inside a directory, if the include points to one). To be able to support multiple preseed and postconfig schemes we can also add tags to declare preseed and postconfig files (i.e. InstallerPressed:, DebconfPressed: and PostconfScript: fields) for each Task. The idea is the same, this information can be used to declare individual files or complete directories, making it compatible with the current Debian-Edu model of one file per task only by adding one or two lines to the pseudo-control file. - And what about a 'flavours' file? besides the file that defines the tasks we can also have an 'optional' file that defines flavours (if the CDD needs them). Basically a flavour would be a list of *tasks* that should be installed together and can be used to generate a menu for the second stage 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. Well, as I've said the menu thing is something I have not studied, but I see no problem in using whatever technique we need to add them, a tagfile seems a very natural way of doing it. Of course the pseudo-control file can add another field to declare what menu entries it is going to use (if we use tagfiles we can point to a tagfile that declares all the task menu entries or simply declare which tags are we going to use to build the menus). > 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. Well, I've changed my proposal to allow anyone choose it's preferred layout: 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. Well, it's more or less the same thing, I still prefer the pseudo-control format anyway, I believe is more powerful (maybe I'm wrong and both are 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. And those are the things I want to define formally, using a set of well documented Standard Fields and usages... the 'X-Field' mechanism allows anybody to test extensions and propose it's inclusion on the standard 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. Well, we can dicuss it further, but yes, your proposal is what I'm calling all the time a pseudo-control file. > However I'd distinguish two levels. I don't really see the need to support *raw* tag definitions, from our point of view everything has to be standarized, if the *raw* tag file is used by a menu generator or other system the files can be included on the CDD definition package as the presseds or the postconf sctipts are, but the package selection list does not need to support them directly. Greetings, Sergio. -- Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/> Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature