[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Feedback about the cdd-dev package and more...

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

> 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.



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

Reply to: