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:
>>
>>Debconf-Preseed
>>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.
>>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
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.
Cheers,
Free
Reply to: