Re: Examples for CDDtool
On Mon, 4 Jul 2005, Sergio Talens-Oliag wrote:
No, that satisfies build dependencies, I want to satisfy normal package
dependencies, the idea is to give apt a list of conflicts, depends,
recommends and suggests and let the system satisfy them, doing the same as
apt does when installing a package that has those dependencies.
Sure, but in principle apt-get recives a list of packages to install
by reading a Packages file. This is what I mean by "it might be
helpful". May be that I'm wrong here but the most basic code for
what we need should be there.
I now had a deeper lock into cddtk and tried to build Debian-Med packages.
The former cdd-dev package was able to build packages for Debian-Jr,
Debian-Edu and Debian-Med. So all I write here is valid for these three
CDDs. I basically use Debian-Med as example.
1) mv tasks desc
Well, I see no real problem in this name change regarding the
"work" to do for the three other CDDs but I see not really in
how far "desc" is better than "tasks". Feel free to do the
final decision about the name - my personal preference would
be the old name.
2) for desc in `ls desc` ; do sed -i "s/^Why/X-Why/" desc/$desc ; done
This is a nice one: I think the "X-" prefix in front of tags
that are not contained in debian/control files is very reasonable
and enhances readability and handling of these files.
3) for desc in `ls desc` ; do sed -i "s/^Responsible/X-Responsible/" desc/$desc ; done
There was no explicite suport of this tag, but marking it with
prefix "X-" gives us the needed flexibility. It is just nice
to know who cares for this part of the task ...
These were the easy ones. Now to some more difficult stuff:
4) vi debian/control
Your example contains short and long description of the meta packages
inside debian/control. In cdd-dev this was easier. The debian/control
file was auto generated from a stub (debian/control.stub) and the
files in tasks (now desc if you want) by cdd-gen-control(1) (see
man page or
This script solves the problem of different target distributions in
a different way: It just verifies the dependencies inside the tasks
(desc) files against the Packages files which are available at the
places which are mentioned in a specified sources.list file. The
drawback of this method compared to your idea is, that the contents
of these Packages files might change inbetween the build time of the
meta package and the installation time while a check at installation
time might have advantages.
On the other hand the generation of a debian/control file has big
advantages which we should merge into your cddtk system. The main
advantage I would see ist that creation of a new meta package can
just be done by putting a single file into the right directory
(tasks / desc). The control.stub file remains untouched. This is
less error prone (no misspelling of names, no descrition file can
be forgotten etc.) Moreover the descriptions are just at the right
place (together with the dependencies and the other stuff.
So I would strongly vote to use the principle of cdd-gen-control
inside the cddtk. This would even avoid problems with the creation
of the substvars files, which I got:
Parse ERROR: '.../debian-med/debian-med-0.10/desc/bio:3':Keyword 'Depends' not allowed on scope 'cddd'
5) There is no code to take over the menu information inside cddtk
(or I just missed it).
I think it is enough for today. I just want to hear what you think about
my suggestions and how we want to proceed before I continue my try and
try to do further enhancements.