Re: Feedback about the cdd-dev package and more...
|--==> 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
Reply to: