Ops, I forgot to answer this message ;)
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?
Well, the idea of Recommends and Suggests comes from the metapackages and it
has a lot of sense to me, the idea is that a task can point to additional
packages related to the task, for example to suggest non-free software or to
recommend a second program that has similar features that one already on the
Depends list.
Note that has to be done on the task, not on the *packages*, because the
Recommends and Suggests are related to the task, not to particular packages,
in fact my idea is that the original package Recommends and Suggests are
going to be ignored when installing a *task* (the user is not going to see
the additional packages), at least on the general case (of course we can add
an option to install them, but it will be set to NO by default).
> 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).
You can do it as you say and not use Recommends and Suggests, but others can
use them.
> 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..
Are you sure? I don't agree, think about a CDD for USB sticks for example,
it can remove some of the Important and Standard packages to reduce it's
size.
> 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.
Perfect, I'll do that on the cdd-tool when building a CDD installer CD
getting the information from the Conflict fields... ;)
> 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.
Please look at http://wiki.debian.net/index.cgi?CDDTool and see if you like
the current proposed fields, I'm mainly interested on the missing ones ;)
> 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.
Great, once I have something available I'll post to the list and we can
comment on adding support for multiple input and output formats, once the
tools work it should be easy to do, but first we need something that works.
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