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