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
Doing:
$ 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
belongs.
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