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

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

El Fri, Dec 03, 2004 at 11:31:56AM +0100, Free Ekanayaka va escriure:
> For  the record  if  you  want  to  express package  level Recommends,
> Suggests, Conflicts you *must*  use the package control file (possibly
> contacting  the maintainer),  I think this    goes without saying.  It
> doesn't make  any  sense  to  me  to  declare  such information   on a
> different level.

  I think you have not understood my proposal, the Recommends, Suggests and
  Conflicts I am talking about are a richer form of declaring the relation of
  a package to a task, with your model a package is in the task or out of it,
  with the control fields (inherited from the *metapackage* nature of the
  current cdd-dev system) you can let the user choose if he wants a minimal
  task installation (installs only Depends), a normal one (including task
  Recommends) or a full installation (including task Recommends and Suggests).

  The Confict field is only to allow someone to *explicitly* remove packages
  with priority Important or Standard (i.e., to let someone force the removal
  of development tools for a minimal system). Maybe it is not needed, but it's
  more or less coherent with the use of the other fields.

> If you  want to declare  task level Suggests,  Conflicts, Recommends I
> provided an example in my previous post, maybe it wasn't clear.
> You have the vocabulary file with the definition of the task tags:
> Tag: task::mytask1
> Description: bla bla
>  more bla bla
> Depends: task::mytask2
> Suggests: task::mytask3
> Conflicts: task::mytask4

  OK, then it can be done on both systems, better.

>   ST>   The main problem I see is that we aproach the problem in using two different
>   ST>   models: you think in terms of individual packages, while I think in terms of
>   ST>   tasks. I want to be able to work on tasks idependently and define relations
>   ST>   between them.
> Yes, but  that's a  thing you can   do with my   model too.  Tasks are
> particular tags,  and  you  declare  relationships  between tags.  See
> above.

  Sure, it's just I and almost everybody else working on CDD (IMHO) is used to
  the control file way of doing things (is similar to the Debian packages we
  work with)

> Having a file (or multiple files  if you prefer)  with *only* the task tag
> declaration, and not  the packages they are  composed of  has also the
> advantage that it's easier to read the task relationships: in case the tasks
> have  lots of packages  the  distance of two  Task: entries might be very
> long in terms of lines.

  Then use one file for each task or a tool to get the information (a simple
  grep is enough).

  No, seriously, I don't really see the problem, if both formats can be easily
  interchangeable we can support both.
  I don't really care too much about the formats, I care about standarization
  and migration paths... the important thing is to know what information we
  need and be able to develop tools to process that information and do what
  we need.

>   ST>   Think that my CDD model needs to support multiple Flavours of the CDD, so a
>   ST>   task has to be able to include the packages already present on other tasks
>   ST>   (posibly configuring it on a different way).
> Ok, if a task needs the packages of second task,  just make it depends
> on it. That's a thing you can do with my model too.
> If you want a package to be present in two different task, just tag it
> accordingly:
> mypackage: task::mytask1, task::mytask2
>   >>Splitting  the tag  definitions     (the  vocabulary) from   the   tag
>   >>application also allow to insert package specific information.
>   >>
>   >>For example I've add a "relevance" tag which is used to distribute the
>   >>packages in CD collection (mycdd-CD1, mycdd-CD2, etc). This way if you
>   >>want a minimal system  you just use CD1,  otherwise  you can get  more
>   >>packages.
>   ST>   Yes, but this can also be done on the pseudo control file and later
>   ST>   translated... 
> Yes  but how  do  you define   the relevance of   a *package*  (not  a
> task). This is useful  to distribute packages over  a CD set, the most
> relevant packages  first and the secondary  ones later. You  should be
> able to have a  functional system with only the  first CD, and use the
> second the third   etc only if you  really  need more  things.  It's a
> feature that it's needed by A/DeMuDi for example.
> I think that with pseudo-control file you need something like:
> Task: mytask1
> Description: bla bla
> Depends: pkg1 (relevance=10), pkg2 (relevance=6)
> which is  fine for me,  but if you need  to add other package specific
> information, like the menu path, you have:
> Task: mytask1
> Description: bla bla
> Depends: pkg1 (relevance=10, menu=Some/Custom/Path), pkg2 (relevance=6, menu=Some/Other/Path)

  Are you sure? This model is not what I have proposed; in fact you are mixing
  package attributes with task attributes, but maybe I missundersdood

  Anyway the relevance atribute and almost all other things can be handlend
  using external files:

    Task: mytask1
    Description: bla bla
    Menu: path/to/file/defining/task_menus
    Relevances: path/to/file/defining/task_package_relevances

    Depends: pkg1, pkg2

  Or simply changing Field values before (or after) declaring depencies:
    Task: mytask1
    Description: bla bla
    Menu: path/to/file/defining/task_menus

    Relevance: 10
    Depends: pkg1

    Relevance: 6
    Depends: pkg2

> Note that the menu entry and the relevance shall be also duplicated in
> case a  package appears in more than  one task. So  why  not having an
> alphabetically ordered list   of packages containing package  specific
> info?

  Oh, then for you each package only has one relevance? why don't we support
  multiple relevances depending on the task? For a CDD that has more than one
  'installation profile' can be interesting (i.e. to build a single profile
  installation CD or a multiprofile one).
  Anyway what I wanted to know is what kind of 'Fields' or 'Attributes' are
  needed, I now see that you want to be able to add information about package
  relevance and associate menu information to packages, the way to implement
  it less important now (I'm sure we will be able to transform between various

>   ST>   Well, as I've said the menu thing is something I have not studied, but I see
>   ST>   no problem in using whatever technique we need to add them, a tagfile seems
>   ST>   a very natural way of doing it. Of course the pseudo-control file can add
>   ST>   another field to declare what menu entries it is going to use (if we use
>   ST>   tagfiles we can point to a tagfile that declares all the task menu entries
>   ST>   or simply declare which tags are we going to use to build the menus).
> So  when  you want to add  a  package you have to  add  it both to the
> pseudo-control file (in  the Depends: stanza of some  task) and in the
> menu tag file,  and if another information   comes out in future  in a
> third file an so on.. Isn't that clean. Am I missing something?

  Yes, that's the idea; depending on the kind of information it belongs to the
  control file or to external files; menus are usually used for applications,
  not for packages, if you put all information related to a task on the same
  place the menus can also be there in whatever format you want:


  The idea is to support 'Fields' inside the 'control' file that can represent
  information directly or point to aditional files without forcing a
  directory layout.
  The good thing is that the contents of each Field can be whatever we want,
  in fact that is what I wanted to talk about; now I know you need to give a
  'relevance' to packages and associate menus to them. Anything else not
  already available?



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: