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;
done
> 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
purposes.
> 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
debian/rules).
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