[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 Wed, Dec 01, 2004 at 10:33:40PM +0100, Enrico Zini va escriure:
  >>On Wed, Dec 01, 2004 at 08:43:46PM +0100, Sergio Talens-Oliag wrote:
  >>>   Comments? Suggestions? Flames?
  >>Everyone wants to specify all the CDD data in a single place, and I
  >>think everyone is kind of doing it in a way or another.

  ST>   OK, so we agree on that!

  >>For example, the new supersimple-cdd-building-script from Vagrant (that
  >>I'd like to see into cdd-dev soon, if possible) does it.  Free told me
  >>he's doing something like that as well.  Everyone is.
  >>I think everyone of us created some code that in some way overlaps with
  >>what the others have done, and I think we share at least the goal of
  >>having a CDD description somewhere, then running make-cdd and have the
  >>ISO images built.
  >>So, the question is: why don't we have that already?
  >>My bet is that if we create a common standard, then for it to be adopted
  >>everyone needs to change the way they work.  This is of course a burden:
  >>it means asking too much to busy people working hard on their agendas.
  ST>   Well, I believe that now we are in a better position than before, I don't
  ST>   want to force anyone to work as I want, I want to integrate the techniques
  ST>   already on place and build common tools to handle them, simplifying things
  ST>   as much as possible.

  ST>   I need to work on cdd-dev to build my own CDD, what I'm looking for now is a
  ST>   consensus on what is needed and how to store the information, once that is
  ST>   agreed on I can build or improve current tools for my pourposes, but
  ST>   including what others request.

  ST>   My proposal can be sumarized as:

  ST>   - We need a system to store tasks, or components, or whatever name people
  ST>     wants to give to a system to select a group of packages and configure
  ST>     them using debconf pre-seeding and postconfiguration scripts.

Yes, that's correct.

  ST>   - I want to work on it and, right now, I only need to standarize and
  ST>     document the way we want to store the input data and what is this input
  ST>     data.
  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.

However I have  to  say that now I  found  more comfortable to  manage
single files.

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.

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

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.

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.

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

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.

Then the semantics  of a  certain tag (e.g.  task, menu,  priority) is
obviously defined by the scripts which parse the data files.

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.

However I'd distinguish two levels.

1) A  "raw" tag definition level, that  is typically used by  a little
   parsing library. At this level a the format is very loose, roughly:

   Tag: type1::name1
   Field1: value1
   Field2: value2

   Tag: type1::name2
   Field1: this field has a very long
    value so that I need another line, prefixed by a space
   Field2: value2

   Tag: type2::name1
   Field1: value1
   Field2: value2

   Of course you can  have as many  fields you want. A  tag definition
   ends with black line. The parser library would return the list of
   defined tags along with their fields-value associations.

2) A tag specific definition, whose fields depends on the tag semantic, e.g.

   Tag: task::mytask1
   Description: this is my first task
   Relevance: 9
   Confilcts: mytask2
   Depends: mytask3
   Action: mark

   this tag defines a  task which will be  displayed by  tasksel among
   the first ones (Relevance 9) and that on new install will be marked
   for installation by default when the tasksel dialog appears.

   Tag: menu::mypath1
   Path: Some/Custom/Path

   this tag defines a menu path.

   Tag: preseed::mypreseed1
   File: /path/to/values

Then you can have one or multiple files containing tag applications:

pkg1: task::mytask1, menu::mypath1, preseed1::mypreseed1

and there will be a couple of scripts which will parse it (for example
when  tasksel is invoked  or  when update-menus  is invoked, these two
programs provide hooks to achieve this).

Well, this are rough idea, need to be elaborated..



  ST>     - package selections: we can keep using the same format being used now, a
  ST>       pseudo control file that includes the following fields:
  ST>       - 'Task':        mandatory (could be taken from the directory name)
  ST>       - 'Description': mandatory (useful and needed for metapackages)

  ST>       - 'Architecture': optional, defaults to 'all'
  ST>       - 'Section': optional, defaults to 'misc' (well, I have to check that)
  ST>       - 'Depends', 'Recommends', 'Suggests': At least one of them is required,
  ST> 	they list the packages we want to include and can be present multiple
  ST> 	times to be able to add *meta-information* for each dependency
  ST> 	(debian-edu adds fields like 'Why', 'Responsible', 'URL', etc.).

  ST> 	The name of the field will imply the same as on the control file, and
  ST> 	will have different effects depending on the target system (i.e. for
  ST> 	tasksel recommends and suggests can be put on diferent tasks, to be
  ST> 	able to not install them)
  ST>       - 'Avoid' (I'll prefer 'Conflicts'): This should not be needed, but
  ST> 	maybe is interesting to be able to declare explicit conflicts ... we
  ST> 	have to discuss it further.

  ST>       I propose to add some extra fields to declare inter-task relationships:

  ST>       - 'Depends-Task', 'Recommends-Task', 'Suggests-Task' and
  ST> 	'Conflicts-Task': Those fields declare relations between the CDD
  ST> 	tasks.

  ST>       And use the prefix 'X-' for all not defined fields (i.e. I would change
  ST>       the debian-edu 'Why' fields per 'X-Why', just to be able to verify the
  ST>       sintax of the files and ignore all 'X-' fields).

  ST>     - preseeds: I will put debconf presseds into two subdirectories of the
  ST>       task directory (one for the system debconf and another for the installer
  ST>       debconf). My original idea is to concatenate all files present to
  ST>       generate a simple preseed, but maybe we should support a richer format
  ST>       to be able to decide if a preseed has to be applied or not (i.e. if we
  ST>       have presseding for Suggested packages maybe we don't want to apply it
  ST>       on some cases). Has to be discussed.

  ST>     - postconfig: Similar to the pressed case, the idea is to include all
  ST>       scripts present on a directory and execute them in order after
  ST>       installation.

  ST>   - Once the formats are clear and we have the tools a CDD can be defined by
  ST>     those files and distributed *in source* form (all the files I'm talking
  ST>     about could be installed into /usr/share/cdd/cdd-name/ and be used
  ST>     by the cdd-tools to generate metapackages, tasks, tagfiles, ... and build
  ST>     cdd apt repositories, generate debian-installer images or live cd versions
  ST>     of the cdd).

  >>How to overcome this?  I don't know yet.
  >>An idea in my mind would be that since in Debian-NP we're thinking of
  >>not being a CDD, but rather a group helping people in making their own
  >>CDD, we are the perfect opportunity to spread what we agree is the best
  >>and more comfortable way to do things.
  >>Once some way of doing things is spread and gets more mature, it can be
  >>considered a better replacement for some hacked script that one is using
  >>and has not time to improve.
  >>Better ideas are however quite welcome.  Also because in Debian-NP we
  >>have rather unpredictable times :)

  ST>   Well, I'm open to cooperation, once we agree on the formats we can try to
  ST>   join forces and do testing toghether ;)

Reply to: