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

Re: Examples for CDDtool

El Tue, Jul 05, 2005 at 12:02:18PM +0200, Andreas Tille va escriure:
> On Tue, 5 Jul 2005, Sergio Talens-Oliag wrote:
> > anyway it has the same solution as before, if you want to use a 
> > description
> > file different than "desc/all" you can put:
> >
> >   export DESC=tasks/all
> Great flexibility, but I would prefer to use just the default in my packages
> (whatever it is).

  I've used 'tasks.dsc' as default file, but I don't have strong feellings
  about it, feel free to suggest other names, while it is a simple filename
  any default is OK for me.

> > Anyway, supporting your existing tasks directory is easy, you only need to
> > include the files of that directory into the main description file (i.e.
> > 'tasks.dsc' or whatever file you put on the debian/rules DESC variable):
> >
> >   rm -f tasks.dsc;
> >   for f in `ls tasks/`; do
> >     echo -e "Include: tasks/$f\n\n" >> tasks.dsc;
> >   done
> Well, I do not remind that I was missing something you mean by
>   "main description file"
> Perhaps I will find out that I would need such a thing later on. :)

  The idea is that each CDD should have only one description that defines all
  the CDD tasks; the description can be split into multiple files using the
  'Include' field, but for the cddtool the description comes from a main
  source file.
  That way you can get information for all the CDD tasks using only one file,
  i.e., if you put yourself on the topdir of the lliurex-cdd package with the
  latest version of the cddtool installed (0.0.12) and do:

    $ cddtool -d desc/all tinfo -l

  You get the list of all available tasks


    $ cddtool -d desc/all tinfo -m

  You get the list of tasks marked as Install-Task or Meta-Task.
  Or doing:

    $ cddtool -d desc/all tinfo -f

  You get a normalized dump of the description file, with comments and X-
  fields removed.

> > I usually check the tasks with the fake-apt script while developing, but 
> > not
> > at compile time (in fact I've generated packages that I knew were wrong 
> > more
> > than once, usually because they were being developed in paralel); anyway 
> > is
> > an optional step that could be added, that is no problem for me.
> It would be nice to have for the moment.  Once we have found a rock solid
> working solution it might be dropped.  Find all necessary code in cdd-dev
> package.

  Ok, I'll take a look and will copy the interesting scripts, but not today.
  I still have to prepare the examples for my tutorial.
> > My original idea is that you don't need a control.stub; the control file
> > only needs the source and the description packages, the metapackages can 
> > be
> > generated automatically from the description file for all Tasks that have
> > the fields 'Meta-Task: True' or 'Install-Task: True'.
> >
> > If you want to generate the metapackages at compile time the metapackages
> > can be appended to the debian/control file, if there is no need to upload
> > them to the debian pool the metapackage control files or can be 
> > distributed
> > with the description package and built when needed on the user system.
> This is what I was seeking for: How can I enforce that a file (say 
> tasks/bio)
> which I tag with
>     Meta-Task: True
>     Install-Task: True
> (if we agree to this new syntax which sounds perfectly reasonable) leads to
> a meta package named med-bio without mentioning it in debian/control.  This
> is what formerly worked and what I would love to get working soon to proceed
> in migration and to offer patches and hints.

  The Install-Task is to mark tasks as installable for the debian-installer,
  if you mark a task as Install-Task it is assumed that the task is also a
  metapackage, so you don't need to put the Meta-Task field; that later field
  is for tasks that you want to be metapackages but don't want to expose
  on the debian-installer task selection list.
> > That is because your description is not right using the cddtk description
> > format, a paragraph must start using the keyword 'Task:', the syntax is
> > stricter than what you where using before...  What are the contents of the
> > previous lines of the bio file?
> I hope that I would not be boring to you - you said it is not ready, but
> just in case it uncovers a problem:
> debian/med-bio.substvars:
> -------------------------
> Error reading description file 'desc/bio':
> Parse ERROR: 
> '/home/tillea/debian-maintain/packages/debian-med/debian-med-0.10/desc/bio:7'
> :Keyword 'Depends' not allowed on scope 'cddd'
> ...
> desc/bio:
> ---------
> Task: bio
> Architecture: all
> Description: Debian-Med micro-biology packages
> Install-Task: true
> X-Responsible: tille@debian.org
> Depends: blast2, bugsx, fastdnaml, fastlink, garlic, hmmer, \
>          loki, ncbi-epcr, ncbi-tools-bin, ncbi-tools-x11, njplot, pymol, \
>          r-cran-qtl, rasmol, readseq, tigr-glimmer, tree-puzzle

  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.

    Package -> Starts/continues with the definition of fields related to a
    package, the paragraph needs to have a preceding Task to which the Package

    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:

     X-Responsible: tille@debian.org
     Task: bio
     Depends: blast2, bugsx, fastdnaml, fastlink, garlic, hmmer, \

   Or mark the blank line as a comment (in that case the line is ignored and
   the parser does not detect a paragraph break):

     X-Responsible: tille@debian.org
     Depends: blast2, bugsx, fastdnaml, fastlink, garlic, hmmer, \
   Note that you can also split your Depends into multiple lines, the parser
   takes care of building the full list:

     X-Responsible: tille@debian.org
     Depends: blast2
     Depends: bugsx
     Depends: fastdnaml, fastlink

> > No, there is no code to process the fields related to menus,
> Do you want me to provide patches or give me SVN access.  I'm unsure what
> might be the bestin the current state of the development.

  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.

> > Note that the substvars system is still used, but it will only generate
> > substvars if it finds a task package in the control file.
> OK, I'll try to understand id I see the new version.

  On my package it is still used, but if you don't put the metatasks on the
  debian/control file the correstponding substvars are not generated.

> BTW, I just faced on a newly installed box that cdbs was not installed.  I
> would suggest to make a "Depends: cdbs" for cddtk.  If you think that this
> is not reasonable I would add it to the Build-Depends of Debian-Med.  I know
> I convinced you to the common cdbs script for cddtk when you were not 
> absolutely
> sure about it, but once this is in a dependency would make sense, IMHO.

  I've put a Recommends on the package, but a Depends does not seem right, as
  the cddtk package can be used without cdbs and the description package can
  be generated without using it either.

> Please don't be shy in case my remarks would keep you away from coding.  I
> just want to be helpful.  If I'm to impatient, just tell me - I will not
> feel insulted in such cases. Thank you for your cooperation so far.

  No, don't worry, your questions have forced me to take a look at the code
  and I've ended up changing things while replying (I started to reply your
  previous mail yesterday, but I've sent it this mornig, as I ended up coding
  and left the answer pending until today).
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: