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

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.


  >>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
  >>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 :)



Reply to: