Re: Feedback about the cdd-dev package and more...
|--==> Sergio Talens-Oliag writes:
ST> [1 <text/plain; us-ascii (quoted-printable)>]
ST> 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.
ST> I think you have not understood my proposal, the Recommends,
ST> Suggests and Conflicts I am talking about are a richer form of
ST> declaring the relation of a package to a task, with your model
ST> a package is in the task or out of it, with the control fields
ST> (inherited from the *metapackage* nature of the current
ST> cdd-dev system) you can let the user choose if he wants a
ST> minimal task installation (installs only Depends), a normal
ST> one (including task Recommends) or a full installation
ST> (including task Recommends and Suggests).
Ok I got it, I didn't understand.
The first think that comes to my mind is that this type of information
(Recommends, Suggests) should be added directly in the control file of
the package, and then you should have a command line flag of tasksel
which additionally installs Recommends/Suggests. I might be wrong but
I think such information worth be added directly in the package, and
should be common rather than "custom".
Do you have real life counter-examples?
A workaround would be to implement Recommends/Suggests at task level.
Instead of:
Task: mytask1
Depends: pkg1
Suggests: pkg2, pkg3
you would write:
Task: mytask1
Depends: pkg1
Suggests-Task: mytask2
Task: mytask2
Depends: pkg2, pkg3
Such workaround can be done in both formats (sto and free).
Finally if we really want to have package based Suggests/Recommends,
than my format should allow constructs like:
pkg1: task::mytask1
pkg2: task::mytask1::suggests
pkg3: task::mytask1::suggests
Not the best, but possible.
ST> The Confict field is only to allow someone to *explicitly* remove packages
ST> with priority Important or Standard (i.e., to let someone force the removal
ST> of development tools for a minimal system). Maybe it is not needed, but it's
ST> more or less coherent with the use of the other fields.
Mmmh, why would you want to remove Important or Standard packages? I
think that the only dev packages in standard are g++ and maybe
libc-dev, which doesn't hurt for minimal system..
Anyway AFAIK Important or Standard packages are installed by the d-i
using debootstrap, if you want to exclude some of them just add them
to the BASE_EXCLUDE variable of your debian-cd configuration file.
>>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
ST> 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.
ST> Sure, it's just I and almost everybody else working on CDD (IMHO) is used to
ST> the control file way of doing things (is similar to the Debian packages we
ST> work with)
This is true. Actually the tag definition format:
Tag: tag_type::tag_name
Field1:
Field2:
...
it's identical to the control file. What changes is the concept of tag
applied to a package:
pkg: tag_type::tag_name, other_type::other_name,
>>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.
ST> Then use one file for each task or a tool to get the information (a simple
ST> grep is enough).
ST> No, seriously, I don't really see the problem, if both formats can be easily
ST> interchangeable we can support both.
Yes, it's just comfort.
ST> I don't really care too much about the formats, I care about standarization
ST> and migration paths... the important thing is to know what information we
ST> need and be able to develop tools to process that information and do what
ST> 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)
ST> Are you sure? This model is not what I have proposed; in fact you are mixing
ST> package attributes with task attributes, but maybe I missundersdood
ST> something.
ST> Anyway the relevance atribute and almost all other things can be handlend
ST> using external files:
ST> Task: mytask1
ST> Description: bla bla
ST> Menu: path/to/file/defining/task_menus
ST> Relevances: path/to/file/defining/task_package_relevances
ST> Depends: pkg1, pkg2
ST> Or simply changing Field values before (or after) declaring depencies:
ST> Task: mytask1
ST> Description: bla bla
ST> Menu: path/to/file/defining/task_menus
ST> Relevance: 10
ST> Depends: pkg1
ST> Relevance: 6
ST> Depends: pkg2
Ok, this second version is better.
>>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?
ST> Oh, then for you each package only has one relevance? why don't we support
ST> multiple relevances depending on the task? For a CDD that has more than one
ST> 'installation profile' can be interesting (i.e. to build a single profile
ST> installation CD or a multiprofile one).
This is a good point.
I guess that with your task oriented approach it's easier to get more
granularity for tasks, while the opposite holds for my package
oriented approach.
You should do something like:
pkg1: task::mytask1, task::mytask2, relevance::mytask1:10, relevance::mytask2::6
but it's somewhat awkward.
ST> Anyway what I wanted to know is what kind of 'Fields' or 'Attributes' are
ST> needed, I now see that you want to be able to add information about package
ST> relevance and associate menu information to packages, the way to implement
ST> it less important now (I'm sure we will be able to transform between various
ST> formats).
Let's just discuss about the best format now, I'll adhere with it as
long as it satisfies my requirements.
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).
>>
Exactly.
>>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?
ST> Yes, that's the idea; depending on the kind of information it belongs to the
ST> control file or to external files; menus are usually used for applications,
ST> not for packages, if you put all information related to a task on the same
ST> place the menus can also be there in whatever format you want:
ST> task/
ST> control
ST> debconf-pressed/
ST> pkg1.presseed
ST> menus/
ST> pkg1.menu
ST> pkg2.menu
ST> ...
ST> The idea is to support 'Fields' inside the 'control' file that can represent
ST> information directly or point to aditional files without forcing a
ST> directory layout.
Good, this is fine for me.
ST> The good thing is that the contents of each Field can be whatever we want,
ST> in fact that is what I wanted to talk about; now I know you need to give a
ST> 'relevance' to packages and associate menus to them. Anything else not
ST> already available?
Well, to come to a conclusion it seems that the two approaches are
almost equivalent, and both have little drawbacks, which you can live
with.
The relevance argument is strong one in favour of the pseudo-control
format, and I to "cut the head of the bull" (in Italy it means to end
up to a conclusion) it's enough convincing for me to drop the tag
based approach, even if I'll miss it's conciseness.
Cheers,
Free
Reply to: