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

Re: CDD Tool Proposal

|--==> Sergio Talens-Oliag writes:

  ST> [1  <text/plain; us-ascii (quoted-printable)>]
  ST> 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.

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

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

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

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

Well, as far as I'm concerned, I don't need  to rewrite the whole menu
entry, I just need to change the section="" field. E.g:

ardour-gtk: "Apps/Sound" -> "Sound/Recorders/Multitrack"

Thus the idea is that I only customise the section/menu-path with:

Pkg-Menu-Path: Sound/Recorders/Multitrack
Depends: ardour-gtk

and then I have  a script in /etc/menu  (or whatever  location), which
can be  common for all CDDs, and  that is invoked  by update-menus and
write on standard out a menu entry identical  to the original one that
comes with the ardour-gtk package, but with the my custom menu path.

This is what I currently do with A/DeMuDi, see:

  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.

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

Yes, I was just wondering what people from Skole use it for.

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

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

  ST>     Field: value1
  ST>     Field: value2
  ST>   Is equivalent to:

  ST>     Field: value1, value2

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

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

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

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

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

Yes  having different  paragraphs  (Task related  and Package related)
makes sense to me.

  ST>     Note that those fields are concatenated if they appear more than once,
  ST>     execept the 'Pkg-Relevance' one, but currently I'm unsure if the field is
  ST>     really needed; if the task depends on a package and the task has to be on
  ST>     the firts CD all dependencies have to be there also, so a package always
  ST>     has the relevance of the highest task included on the CD.
  ST>     Note that Recommends and Suggests don't have to follow this rule, but
  ST>     maybe we could define the task Relevance field as a three value list,
  ST>     declaring the Depends, Recommends and Suggests relevances as a tuple. If
  ST>     the task Relevance only defines one value we use will use that for
  ST>     packages on Depends and assign he lowest one to Suggested packages and the
  ST>     next one to the packages included on Recommends.
Well, I   think that a threefold   valued Relevance, implemented using
Depends Recommends Suggests, is fine as far as my CDD is concerned. If
we need something more complex we can add it later..

  ST>   What do others think about this proposal? If everybody agrees I'll update
  ST>   the proposal with this new syntactical and semantical changes.

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

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

Good, much better.

  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.

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

I have good knowledge of almost  all the sub-tools which cdd-tool will
need (e.g. debian-cd,  tasksel, base-config, the   d-i, menu). If  you
need a hand in implementing something please let me know.



Reply to: