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
idea:
Task-Menu: Name of a file or directory containing menu definitions for the
task.
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.
Greetings,
Sergio.
--
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