Hello Andreas,
On Fri, Jul 26, 2013 at 12:36 AM, Andreas Tille <[email protected]> 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
