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

Re: Examples for CDDtool

El Tue, Jul 05, 2005 at 02:49:24PM +0200, Andreas Tille va escriure:
> On Tue, 5 Jul 2005, Sergio Talens-Oliag wrote:
> > The bug is on the blank line between X-Responsible and Depends, the 
> > cddtool
> > description works using 'paragraphs' that can start with three different
> > Fields right now:
> >
> >   Include -> It's replaced by the contents of the file it refers to
> >
> >   Task -> Starts/continues with the definition of a task and can be 
> >   followed
> >   by other Task paragraphs or Package paragraphs.
> Just for my personal understanding: If a "Task" results in a meta package
> what is then a ...
> >   Package -> Starts/continues with the definition of fields related to a
> >   package, the paragraph needs to have a preceding Task to which the 
> >   Package
> >   belongs.
> ... "Package"?  A Dependency of the meta package or rather further 
> specification
> of the meta package of the given "Task".

  The original purpose of the field was to use it to add meta-information
  related to packages included on the task, declaring that a set of fields
  like Cfg-Scripts, Debconf-Preseed, Pkg-Relevance, Menu entries, etc. are
  related to the given package inside the Task.

  In practice I'm not using it, as almost everything can be expressed at the
  task level (i.e., if preseedings are put next to dependencies the
  relationship of the presseding with the packages is clear for a person 
  reading the description).
  Originally the idea was that knowing that a field was related to a Package
  was going to be useful (i.e. for upgrades), but unconciously I've been
  moving this information to other places, as I've done for cfg-scripts (the
  current proposal is available on the cddtk-runtime package or from

> >   If you want to use blank lines to separate a Task definition you need to
> >   start the second paragraph with a Task field with the same name:
> OK.  This did not occured to me because I just had one control file per
> task.  This would need only one single "Task:" definition per file and any
> specifications inside this file were related to this Task (and in
> consequence to the resulting meta package).  So I see your point that in the
> case of the "single description file approach" you need to tag the related
> task.  I will keep this in mind.
> On the other hand wouldn't it be an option to have a "current task" which is
> valid until there is a new "Task:" definition.  Anyway, this is a minor
> thing and nothing we should spend much time on.

  Yes, that was considered but I removed it as it seemed more consistent with
  the Control file paragraphs idea and to avoid surprises when including files
  (with the current system you are forced to declare the task or package you
  are working with on each file, avoiding the inclusions of unexpected
  dependencies on the wrong tasks).
  If you feel it is important we can change it in the future, but once you get
  used to the syntax it doesn't really matters.

> > Sure, I'll add an user for you (tillea) and I'll send you a private mail
> > with a password and instuctions on how to change it.
> On the other hand you might think about adding a cddtk tree in the CDD
> alioth project.  There is even space next to projects{med,junior} for
> lliurex.  Anything against this approach.  In this case cddtk would stay at
> the place where it finally belongs to, right?

  No, I have nothing against it, it's simply that with the current situation I
  have a better access to the server (it's in my house ;), but I can put the
  code on alioth if everybody agrees.

  The lliurex packages will be kept in our servers, as the svn will be
  available from a trac installation with a bugtracker and a wiki. In fact
  that's one of my pending tasks for this month, reorganize our internal svn
  repository (it is a mess right now) and open various projects inside that
  trac installation.
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: