Re: Examples for CDDtool
On Tue, 5 Jul 2005, Sergio Talens-Oliag wrote:
Not really important, I can change the default to tasks without problem,
I might be biased for historical reasons but in the directory you can find
definitions of "tasks" - that's why I have a slight preference. Just find
a final conclusion - I'll adopt if necessary.
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 added a default description file name for the cddtool (if there is no
-d argument it uses 'tasks.dsc', if it exists).
I've also removed the support for the 'desc/$TASK' if there is no 'desc/all'
or '$DESC' file from the cdbs-helper script, as I feel is better to get all
the tasks from the same file (the full description is checked to generate
each task).
I'm afraid I do not really understand what you did because of a lack of knowledge
about cddtool internals - but I trust you that you did the right thing. ;-)
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. :)
I've told you that the current code was not finished, all this information
can be taken from the description file and put into a generated control file
or put there using substvars (I have to verify that all can be in
substvars, as I'm unsure if the full description would be substituted, as it
is a multiline value)
OK, fine if it is your plan to generate a control file as it is done in
ccd-gen-control - just forget about my comments. I just wanted to make sure
that you are aware that we currently missing something. (Leaning back and
waiting. ;-) )
I don't verify dependencies against a sources.list, doing it at package
build time seemed an overkill to me.
Well, I was never convinced that it was the optimal solution but it was
just implemented (if I remember right by Petter) and it worked so far.
I just wanted to bring this into the discussion.
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.
At install time the test is already available, as the metapackage
installation is the test, if it can't be installed we have a bug on the CDD
against the given repository.
This might be a little bit late for a rollout. :)
I found it very convenient to build the meta packages for stable/testing/unstable
by just symlinking /etc/cdd/sources.list to the relevant file and beeing sure that
these meta packages work (for the moment!) at the target distribution. The only
problem that this method shows is that you might have different packages for
different /etc/cdd/sources.list file which would have the same version number.
Thus the usage of the "-s <dist>" option of cdd-gen-control should be enforced.
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.
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
...
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.
I have added the control file generation code to the svn version of the tool
and I've put code to the cdbs-helper to generate the control file of all the
tasks marked as meta (currently they are distributed with the man package,
copied on /etc/CDD/tasks/$TASK/control, that's the way I planned to
distribute them, but if you prefer to generate the metapackages at compile
time it's simply a matter of append those files to the control file on the
debian/rules).
I'll check it out this evening.
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.
One thing I would like to comment is the cddtool invocation syntax, I
changed it this weekend but I don't like how it ended, it was too confusing.
Yesterday I went back to the 'tdeps', 'tinfo' and 'tmeta' subcommands and
removed the 'tasks' subcommand.
OK.
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.
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.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: