Re: Feedback about the cdd-dev package and more...
|--==> 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
Reply to: