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

Re: CDD Tool Proposal

El Thu, Dec 09, 2004 at 08:20:19AM +0100, Free Ekanayaka va escriure:
> |--==> Andreas Tille writes:
>   AT> On Tue, 7 Dec 2004, Sergio Talens-Oliag wrote:
>   AT> Comments to the Wiki:
>   AT> Control File Fields
>   AT>     Include
>   AT>       Very good idea which more or less should handle personal preferences.
>   AT>     Task-Menu
>   AT>       Please make sure that it is possible to provide menu overrides for
>   AT>       single packages in each single meta package as it is done in Debian-Med
>   AT>       (version 0.8.9)
> I'd add also something like:
> Pkg-Menu: My/Custom/Path
> if it's declared then the package(s) included in subsequent Depends/Recommends/Suggests
> will have the standard menu path overridden by that custom path.

  Hmm, I don't really see how this would work right now, but I'll add it to
  the proposal if you explain it more; if the field is going to be used to
  define a path maybe the name should be Pkg-Menu-Path; if you mean that all
  menu definitions are stored on this path the Task-Menu field supports that
    Task-Menu: Name of a file or directory containing menu definitions for the

  My idea is that all the menus related to a task can be put into a directory
  and included only once:
    Task: Foo1
    Task-Menu: menus/
  or each set of packages can declare the menus realated to it independently:

    Task: Foo2
    Depends: package1
    Task-Menu: menus/program1.1.menu, menus/program1.2.menu
    # Includes two menu files on the task

    Depends: package2
    Task-Menu: menus/package2/
    # Includes all menu files present on the directory to the task

>   AT>     Base-Config and Base-Config-Menu
>   AT>       I do not really know this stuff but I guess this is needed for installation,
>   AT>       right?
> Yes, but I don't understand why one would put files in /usr/lib/base-config..
> Isn't /usr/lib/base-config/menu enough for all base-config related things?
> AFAIR Skole does use /usr/lib/base-config and  maybe others too, but I
> don't see why.

  Well, my first version of the proposal used only Base-Config-Menu, but I saw
  that Skolelinux was using /usr/lib/base-config/ and added the field.
  Once I start working on the base-config stuff I'll see if I need it, but
  there is no problem on having the Field now if we now that there is people
  using it.

> Other comments:
>   Debconf-Preseed
>     as for the menu I'd like to be able to specify this information on per-package
>     basis, e.g.

  You can put all Fields related to a package together, but each field is
  later used as one; the original idea was that all Fields can be written
  more than once and their occurrences are concatenated.
  For almost the all fields the idea is that the value applies to the task
  globally; if the field is present more than once the values are
  concatenated, i.e.:

    Field: value1
    Field: value2
  Is equivalent to:

    Field: value1, value2

  The problem is that while discussing I have introduced a new kind of
  field and the Field handling is no longer consistent.

  My original idea was that we were working with the task as a whole and all
  the fields could be seen as one, at least from the task point of view; some
  of the fields could have multiple occurrences and it's values would be
  concatenated and others are one time only and multiple ocurrences override
  the original value (i.e. the first ones: Description, Architecture, Section,
  etc.), but we had no package related information on the control file.
  If we want to support package related information on the control file I'll
  probably have to change the configuration file syntax handling; maybe the
  right approach would be to have to kind of paragraphs:
  - Task paragraphs, that define Fields that are related to the whole task,
    with the information included directly on the control file:
    - Description,
    - Architecture, 
    - Section,
    - Relevance, (we don't need to use the Task- prefix, now it is clear that
      it applies to the full Task)
    - Task-(Depends|Recommends|Suggests|Conflicts)
    or on external files or directories:
    - Base-Config, Base-Config-Menu,
    - Installer-Pressed, Debconf-Preseed, 
    - Cfg-Scripts, Cfg-Scripts-Depends,
    - Menu, (same thing as with Relevance, we can drop the Menu- prefix)

    Note that the Task paragraph can appear more than once with the same name,
    but the repeated field values are overwritten if they include the
    information directly on the control file or the values are concatenated if
    they refence external files.

  - Package related paragraphs, which start with fields that include or
    exclude packages:
    - (Depends|Recommends|Suggests),
    - Conflicts
    Allow the inclusion of external files (the file references are
    concatenated with the Task paragraph fields):

     - Base-Config, Base-Config-Menu,
     - Installer-Pressed, Debconf-Preseed,
     - Cfg-Scripts, Cfg-Scripts-Depends,
     - Menu,
    And extra fields related to the given package with information on the
    control file:
    - Pkg-Installer-Pressed, Pkg-Debconf-Preseed,
    - Pkg-Menu,
    - Pkg-Relevance

    Note that those fields are concatenated if they appear more than once,
    execept the 'Pkg-Relevance' one, but currently I'm unsure if the field is
    really needed; if the task depends on a package and the task has to be on
    the firts CD all dependencies have to be there also, so a package always
    has the relevance of the highest task included on the CD.
    Note that Recommends and Suggests don't have to follow this rule, but
    maybe we could define the task Relevance field as a three value list,
    declaring the Depends, Recommends and Suggests relevances as a tuple. If
    the task Relevance only defines one value we use will use that for
    packages on Depends and assign he lowest one to Suggested packages and the
    next one to the packages included on Recommends.
  What do others think about this proposal? If everybody agrees I'll update
  the proposal with this new syntactical and semantical changes.

>     Pkg-Debconf-Preseed
>     This way I'd have all the information relevant for a certain package in a
>     single place:
>     Pkg-Relevance:              4
>     Pkg-Debconf-Preseed:        key1=value1, key2=value2
>     Pkg-Menu:                   My/Custom/Path
>     Depends:                    somepkg
>     So we may split Dedbconf-Preseed in Pkg-Debconf-Preseed (with the above semantics)
>     and Task-Debconf-Preseed with the same semantics as the current Debconf-Preseed

  Well this is more or less what I have proposed before, the only difference
  is that originally all fields like Pkg-Relevance changed it's value and kept
  the new one for the following paragraphs, but now the value is only valid
  inside the same paragraph (and does not need to be written before the
  Depends line)

>   AT> The CDD Tool
>   AT>     As mentioned above if you plan to use cdd-tool for both, building the
>   AT>     meta packages *and* management of CDDs on the CDD-System an extra
>   AT>     dependency from Python would not really be in the interest of people
>   AT>     who want to build a "minimalistic" CDD.  Please check whether the
>   AT>     extra comfort of Python is worth making some people angry.
>   AT> In general I *really* like your plan and would be proud to be your first
>   AT> alpha tester.
> Me too, you have one more tester and optionally coder/reviewer.

  Great, I believe we are on the good way, I'll try to work on it and have
  something to test soon.



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: