|--==> Sergio Talens-Oliag writes: ST> [1 <text/plain; us-ascii (quoted-printable)>] ST> Ops, I forgot to answer this message ;)
ST> El Fri, Dec 03, 2004 at 02:44:52PM +0100, Free Ekanayaka va escriure: >>|--==> Sergio Talens-Oliag writes: 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? ST> Well, the idea of Recommends and Suggests comes from the metapackages and it ST> has a lot of sense to me, the idea is that a task can point to additional ST> packages related to the task, for example to suggest non-free software or to ST> recommend a second program that has similar features that one already on the ST> Depends list. ST> Note that has to be done on the task, not on the *packages*, because the ST> Recommends and Suggests are related to the task, not to particular packages, ST> in fact my idea is that the original package Recommends and Suggests are ST> going to be ignored when installing a *task* (the user is not going to see ST> the additional packages), at least on the general case (of course we can add ST> an option to install them, but it will be set to NO by default). Ok, got it. >>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). ST> You can do it as you say and not use Recommends and Suggests, but others can ST> use them. Yes, of course we have to allow freedom wherever 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.. ST> Are you sure? I don't agree, think about a CDD for USB sticks for example, ST> it can remove some of the Important and Standard packages to reduce it's ST> size. Ok. >>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. ST> Perfect, I'll do that on the cdd-tool when building a CDD installer CD ST> getting the information from the Conflict fields... ;) Yes, that's a good idea as the debian-cd conf file shall be automatically generated and not manually edited. 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> Please look at http://wiki.debian.net/index.cgi?CDDTool and see if you like ST> the current proposed fields, I'm mainly interested on the missing ones ;) See my other reply. >>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. ST> Great, once I have something available I'll post to the list and we can ST> comment on adding support for multiple input and output formats, once the ST> tools work it should be easy to do, but first we need something that works. Personally I'm too lazy for that, I'll definite stick to the "standard" format :) Cheers, Free
