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

Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)



Hello Andreas,


On Fri, Jul 26, 2013 at 12:36 AM, Andreas Tille <andreas@an3as.eu> wrote:
[Petter, please read below about packages.txt and avoidpackages.txt]

I guess yes, we need the different taskdesc files because tasksel has no
better mechanism.  The alternative would be that you do some postprocessing
in the rules file according to some markers you could leave in a similar
way as in the control file.  So either you keep what we have and just install
the proper file in the rules file or you do some magic like

   grep -v "!<arch>" tasksel | sed 's/\[.*\]//'

or something like this in the rules file to strip some tasksel template
for final use.

I tried to do it that way by generating a taskdesc.template(in case of alternatives I include the first package of the relation). To make sure that we generate proper single-arch taskdescription file from the tasksel template I wrote test_taskdesc script. The latter converts the tasksel template for each <arch> and compares it with the taskdesc-sec/blend-tasks.desc.<arch>.  At first it seems ok, where we get exact the same taskdesc file for almost all Blends/archs, but it does not handle properly the alternatives(the bug appears two times).

First case: in Blend debian-games in task "roguelike" we have:

nethack-qt | nethack-x11 | nethack-console | nethack-el

In the template I include only the first alternative: nethack-qt [!hurd-i386]
In this case of hurd-i386 arch the nethack-qt will be removed from the template, but in the first alternative relation ( nethack-qt | nethack-x11 | nethack-console | nethack-el) the nethack-el is architecture indenpendent("all") so the it should be included in the taskfile(as it correcty does in the taskdesc.<arch> for the hurd-i386 )

Second case: in Blend debian-science in task nanoscale-physics
From the alternatives "openmpi-bin | mpich2 | mpich-bin"  "openmpi-bin" goes into the tasksel template
but it does not appear for mips, s390, s390x archs(but in this archs "mpich2" is available and should take the place of the openmpi-bin as it correctly does in  the taskdesc.<arch> files )

So I should handle the alternatives differently. The good thing is that with test_taskdesc script I can properly check if I cover the problems with the alternative packages. In case other tasksel.template approaches  are not successful we can stick with the multiple .<arch> files for this one.

 
> In order to complete orig source tarball to build the metapackages, I need
> to imitate the current blends-devtools right?

I think they do not really need much change - but reviewing might
definitely not harm.

> That means for example I am
> going to use the files blends/devtools and adapt them to the new code.
> Which other files do I need?

I have not fully made up my mind but IMHO the diff to the current
blends-dev should be not very large.  It just processes an existing
orig.tar.gz tarball and the main work to create this was switching to
UDD.

> Also in the current blends/devtools/Makefile you generate the
>
> * packages.txt : these should be the available packages we have?
> * avoidpackages.txt : the avoided package.

That's part of the orig.tar.gz creation.  We should ask Debian Edu
people if these will be needed in future.  I totally forget about these
because I'm not using these.

> Am I also going to generate these files too?

Petter might answer this question.

Ok as soon as I finish testing the taskdesc template I will imitate the rest of the files of current blends-dev. Now about the avoidpackages.txt/packages.txt  we wait Debian-edu people or Peter to answer?


Kind regards

Emmanouil


Reply to: