[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:
  >>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:
  >>which is contained in a single file, and then used the defined tags to
  >>mark packages:
  >>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),


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

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

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

  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

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

  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::).



Reply to: