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

Re: Examples for CDDtool

El Mon, Jul 04, 2005 at 10:52:13PM +0200, Andreas Tille va escriure:
> 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.

  Well, the code is in apt, sure, but when I looked at it it seemed that I had
  to dig a little bit to find the code I wanted.

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

  Not really important, I can change the default to tasks without problem,
  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

  on the debian/rules file.
  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).
  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;

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

  Yes, that was the idea; you can always use comments for the same purpose,
  but probably in the future we can print the X- fields if the user asks for
  them, as they can be used to extend the description format for special

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

  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)

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

  I don't verify dependencies against a sources.list, doing it at package
  build time seemed an overkill to me.
  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.
  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.

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

  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.

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

  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?

>   5) There is no code to take over the menu information inside cddtk (or I
>   just missed it).

  No, there is no code to process the fields related to menus, preseedings or
  cfg-scripts right now, I'll add them soon, as I will need them during this
  month (i.e. next week I'll work on the debian installer support and I'll
  need preseeding for 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.

  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

  Note that the substvars system is still used, but it will only generate
  substvars if it finds a task package in the control file.

  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.
Sergio Talens-Oliag <sto@debian.org>   <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F  1BD9 548C  8F15 86EF  6770 052B  B8C1 FA69

Attachment: signature.asc
Description: Digital signature

Reply to: