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

  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?

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

Finally if  we really want  to have package based Suggests/Recommends,
than my format should allow constructs like:

pkg1: task::mytask1
pkg2: task::mytask1::suggests
pkg3: task::mytask1::suggests

Not the best, but 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..

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.

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

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

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

This is true. Actually the tag definition format:

Tag: tag_type::tag_name

it's identical to the control file. What changes is the concept of tag
applied to a package:

pkg: tag_type::tag_name, other_type::other_name,

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

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

  ST>   No, seriously, I don't really see the problem, if both formats can be easily
  ST>   interchangeable we can support both.

Yes, it's just comfort.
  ST>   I don't really care too much about the formats, I care about standarization
  ST>   and migration paths... the important thing is to know what information we
  ST>   need and be able to develop tools to process that information and do what
  ST>   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
  >>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
  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)

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

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

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

  ST>     Depends: pkg1, pkg2

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

  ST>     Relevance: 10
  ST>     Depends: pkg1

  ST>     Relevance: 6
  ST>     Depends: pkg2

Ok, this second version is better.

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

  ST>   Oh, then for you each package only has one relevance? why don't we support
  ST>   multiple relevances depending on the task? For a CDD that has more than one
  ST>   'installation profile' can be interesting (i.e. to build a single profile
  ST>   installation CD or a multiprofile one).

This is a good point.

I guess that with your task oriented approach  it's easier to get more
granularity  for   tasks, while  the  opposite  holds  for  my package
oriented approach.

You should do something like:

pkg1: task::mytask1, task::mytask2, relevance::mytask1:10, relevance::mytask2::6

but it's somewhat awkward.
  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> 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?

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

  ST>     task/
  ST>       control
  ST>       debconf-pressed/
  ST>         pkg1.presseed
  ST>       menus/
  ST>         pkg1.menu
  ST>         pkg2.menu
  ST> 	...

  ST>   The idea is to support 'Fields' inside the 'control' file that can represent
  ST>   information directly or point to aditional files without forcing a
  ST>   directory layout.

Good, this is fine for me.
  ST>   The good thing is that the contents of each Field can be whatever we want,
  ST>   in fact that is what I wanted to talk about; now I know you need to give a
  ST>   'relevance' to packages and associate menus to them. Anything else not
  ST>   already available?

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.



Reply to: