Re: Examples for CDDtool
On Tue, 5 Jul 2005, Sergio Talens-Oliag wrote:
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.
OK. Just use this. I'm not keen on inventing names. ;-)
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.
OK - I just have to learn this new philosophy. It is probably more solid
than just taking the files from the task directory. If something would be left
as a backup or whatever in this directory this would cause a new meta package
which was definitely not the best solution. So I will move my stuff to this.
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:
...
Sounds very reasonable.
Ok, I'll take a look and will copy the interesting scripts, but not today.
It is not necessary today. It is perfectly enought if you just agree to
include it because I'm currently busy to prepare my CDD talk for debconf.
It would be stupid to talk about something which will be dropped a week
later or rather never implemented. This is just the reason why I'm bothering
you with questions. ;-)
I still have to prepare the examples for my tutorial.
... which might be even more interesting for me than implementing the things
above.
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".
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.
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?
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.
OK, fine. So I would add it to debian-med Build-Depends for the moment.
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).
:)
I hope my questions will keep on heving t his effect. ;-)
Thanks for your fine work
Andreas.
--
http://fam-tille.de
Reply to: