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

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;
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

 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:

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'

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
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.

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


Reply to: