El Fri, Dec 03, 2004 at 11:31:56AM +0100, Free Ekanayaka va escriure:
> For the record if you want to express package level Recommends,
> Suggests, Conflicts you *must* use the package control file (possibly
> contacting the maintainer), I think this goes without saying. It
> doesn't make any sense to me to declare such information on a
> different level.
I think you have not understood my proposal, the Recommends, Suggests and
Conflicts I am talking about are a richer form of declaring the relation of
a package to a task, with your model a package is in the task or out of it,
with the control fields (inherited from the *metapackage* nature of the
current cdd-dev system) you can let the user choose if he wants a minimal
task installation (installs only Depends), a normal one (including task
Recommends) or a full installation (including task Recommends and Suggests).
The Confict field is only to allow someone to *explicitly* remove packages
with priority Important or Standard (i.e., to let someone force the removal
of development tools for a minimal system). Maybe it is not needed, but it's
more or less coherent with the use of the other fields.
> If you want to declare task level Suggests, Conflicts, Recommends I
> provided an example in my previous post, maybe it wasn't clear.
>
> You have the vocabulary file with the definition of the task tags:
>
> Tag: task::mytask1
> Description: bla bla
> more bla bla
> Depends: task::mytask2
> Suggests: task::mytask3
> Conflicts: task::mytask4
OK, then it can be done on both systems, better.
> ST> The main problem I see is that we aproach the problem in using two different
> ST> models: you think in terms of individual packages, while I think in terms of
> ST> tasks. I want to be able to work on tasks idependently and define relations
> ST> between them.
>
> Yes, but that's a thing you can do with my model too. Tasks are
> particular tags, and you declare relationships between tags. See
> above.
Sure, it's just I and almost everybody else working on CDD (IMHO) is used to
the control file way of doing things (is similar to the Debian packages we
work with)
> Having a file (or multiple files if you prefer) with *only* the task tag
> declaration, and not the packages they are composed of has also the
> advantage that it's easier to read the task relationships: in case the tasks
> have lots of packages the distance of two Task: entries might be very
> long in terms of lines.
Then use one file for each task or a tool to get the information (a simple
grep is enough).
No, seriously, I don't really see the problem, if both formats can be easily
interchangeable we can support both.
I don't really care too much about the formats, I care about standarization
and migration paths... the important thing is to know what information we
need and be able to develop tools to process that information and do what
we need.
> ST> Think that my CDD model needs to support multiple Flavours of the CDD, so a
> ST> task has to be able to include the packages already present on other tasks
> ST> (posibly configuring it on a different way).
>
> Ok, if a task needs the packages of second task, just make it depends
> on it. That's a thing you can do with my model too.
>
> If you want a package to be present in two different task, just tag it
> accordingly:
>
> mypackage: task::mytask1, task::mytask2
>
> >>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
> >>packages.
>
> ST> Yes, but this can also be done on the pseudo control file and later
> ST> translated...
>
> Yes but how do you define the relevance of a *package* (not a
> task). This is useful to distribute packages over a CD set, the most
> relevant packages first and the secondary ones later. You should be
> able to have a functional system with only the first CD, and use the
> second the third etc only if you really need more things. It's a
> feature that it's needed by A/DeMuDi for example.
>
> I think that with pseudo-control file you need something like:
>
> Task: mytask1
> Description: bla bla
> Depends: pkg1 (relevance=10), pkg2 (relevance=6)
>
> which is fine for me, but if you need to add other package specific
> information, like the menu path, you have:
>
> Task: mytask1
> Description: bla bla
> Depends: pkg1 (relevance=10, menu=Some/Custom/Path), pkg2 (relevance=6, menu=Some/Other/Path)
Are you sure? This model is not what I have proposed; in fact you are mixing
package attributes with task attributes, but maybe I missundersdood
something.
Anyway the relevance atribute and almost all other things can be handlend
using external files:
Task: mytask1
Description: bla bla
Menu: path/to/file/defining/task_menus
Relevances: path/to/file/defining/task_package_relevances
Depends: pkg1, pkg2
Or simply changing Field values before (or after) declaring depencies:
Task: mytask1
Description: bla bla
Menu: path/to/file/defining/task_menus
Relevance: 10
Depends: pkg1
Relevance: 6
Depends: pkg2
> Note that the menu entry and the relevance shall be also duplicated in
> case a package appears in more than one task. So why not having an
> alphabetically ordered list of packages containing package specific
> info?
Oh, then for you each package only has one relevance? why don't we support
multiple relevances depending on the task? For a CDD that has more than one
'installation profile' can be interesting (i.e. to build a single profile
installation CD or a multiprofile one).
Anyway what I wanted to know is what kind of 'Fields' or 'Attributes' are
needed, I now see that you want to be able to add information about package
relevance and associate menu information to packages, the way to implement
it less important now (I'm sure we will be able to transform between various
formats).
> ST> Well, as I've said the menu thing is something I have not studied, but I see
> ST> no problem in using whatever technique we need to add them, a tagfile seems
> ST> a very natural way of doing it. Of course the pseudo-control file can add
> ST> another field to declare what menu entries it is going to use (if we use
> ST> tagfiles we can point to a tagfile that declares all the task menu entries
> ST> or simply declare which tags are we going to use to build the menus).
>
> So when you want to add a package you have to add it both to the
> pseudo-control file (in the Depends: stanza of some task) and in the
> menu tag file, and if another information comes out in future in a
> third file an so on.. Isn't that clean. Am I missing something?
Yes, that's the idea; depending on the kind of information it belongs to the
control file or to external files; menus are usually used for applications,
not for packages, if you put all information related to a task on the same
place the menus can also be there in whatever format you want:
task/
control
debconf-pressed/
pkg1.presseed
menus/
pkg1.menu
pkg2.menu
...
The idea is to support 'Fields' inside the 'control' file that can represent
information directly or point to aditional files without forcing a
directory layout.
The good thing is that the contents of each Field can be whatever we want,
in fact that is what I wanted to talk about; now I know you need to give a
'relevance' to packages and associate menus to them. Anything else not
already available?
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