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

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
        http://people.debian.org/~tille/cdd/ap-DevelDescription.en.html#s-cdd-gen-control(1)

     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.

Kind regards

           Andreas.

--
http://fam-tille.de



Reply to: