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

Re: Feedback about the cdd-dev package and more...

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.



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

Reply to: