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

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

El Wed, Dec 01, 2004 at 10:33:40PM +0100, Enrico Zini va escriure:
> On Wed, Dec 01, 2004 at 08:43:46PM +0100, Sergio Talens-Oliag wrote:
> >   Comments? Suggestions? Flames?
> Everyone wants to specify all the CDD data in a single place, and I
> think everyone is kind of doing it in a way or another.

  OK, so we agree on that!

> For example, the new supersimple-cdd-building-script from Vagrant (that
> I'd like to see into cdd-dev soon, if possible) does it.  Free told me
> he's doing something like that as well.  Everyone is.
> I think everyone of us created some code that in some way overlaps with
> what the others have done, and I think we share at least the goal of
> having a CDD description somewhere, then running make-cdd and have the
> ISO images built.
> So, the question is: why don't we have that already?
> My bet is that if we create a common standard, then for it to be adopted
> everyone needs to change the way they work.  This is of course a burden:
> it means asking too much to busy people working hard on their agendas.
  Well, I believe that now we are in a better position than before, I don't
  want to force anyone to work as I want, I want to integrate the techniques
  already on place and build common tools to handle them, simplifying things
  as much as possible.

  I need to work on cdd-dev to build my own CDD, what I'm looking for now is a
  consensus on what is needed and how to store the information, once that is
  agreed on I can build or improve current tools for my pourposes, but
  including what others request.

  My proposal can be sumarized as:

  - We need a system to store tasks, or components, or whatever name people
    wants to give to a system to select a group of packages and configure
    them using debconf pre-seeding and postconfiguration scripts.

  - I want to work on it and, right now, I only need to standarize and
    document the way we want to store the input data and what is this input
    My current proposal is to put all files related to a 'task' inside a
    directory; currently I have three different kind of inputs:
    - package selections: we can keep using the same format being used now, a
      pseudo control file that includes the following fields:
      - 'Task':        mandatory (could be taken from the directory name)
      - 'Description': mandatory (useful and needed for metapackages)

      - 'Architecture': optional, defaults to 'all'
      - 'Section': optional, defaults to 'misc' (well, I have to check that)
      - 'Depends', 'Recommends', 'Suggests': At least one of them is required,
	they list the packages we want to include and can be present multiple
	times to be able to add *meta-information* for each dependency
	(debian-edu adds fields like 'Why', 'Responsible', 'URL', etc.).

	The name of the field will imply the same as on the control file, and
	will have different effects depending on the target system (i.e. for
	tasksel recommends and suggests can be put on diferent tasks, to be
	able to not install them)
      - 'Avoid' (I'll prefer 'Conflicts'): This should not be needed, but
	maybe is interesting to be able to declare explicit conflicts ... we
	have to discuss it further.

      I propose to add some extra fields to declare inter-task relationships:

      - 'Depends-Task', 'Recommends-Task', 'Suggests-Task' and
	'Conflicts-Task': Those fields declare relations between the CDD

      And use the prefix 'X-' for all not defined fields (i.e. I would change
      the debian-edu 'Why' fields per 'X-Why', just to be able to verify the
      sintax of the files and ignore all 'X-' fields).

    - preseeds: I will put debconf presseds into two subdirectories of the
      task directory (one for the system debconf and another for the installer
      debconf). My original idea is to concatenate all files present to
      generate a simple preseed, but maybe we should support a richer format
      to be able to decide if a preseed has to be applied or not (i.e. if we
      have presseding for Suggested packages maybe we don't want to apply it
      on some cases). Has to be discussed.

    - postconfig: Similar to the pressed case, the idea is to include all
      scripts present on a directory and execute them in order after

  - Once the formats are clear and we have the tools a CDD can be defined by
    those files and distributed *in source* form (all the files I'm talking
    about could be installed into /usr/share/cdd/cdd-name/ and be used
    by the cdd-tools to generate metapackages, tasks, tagfiles, ... and build
    cdd apt repositories, generate debian-installer images or live cd versions
    of the cdd).

> How to overcome this?  I don't know yet.
> An idea in my mind would be that since in Debian-NP we're thinking of
> not being a CDD, but rather a group helping people in making their own
> CDD, we are the perfect opportunity to spread what we agree is the best
> and more comfortable way to do things.
> Once some way of doing things is spread and gets more mature, it can be
> considered a better replacement for some hacked script that one is using
> and has not time to improve.
> Better ideas are however quite welcome.  Also because in Debian-NP we
> have rather unpredictable times :)

  Well, I'm open to cooperation, once we agree on the formats we can try to
  join forces and do testing toghether ;)

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: