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

[Andreas Tille <andreas@an3as.eu>]

Hi Emmanouil,

On Fri, Jul 26, 2013 at 05:27:30PM +0300, Emmanouil Kiagias wrote:
> > 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]

I think it is not the right way to go to put only the first alternative
into the taskdesc file.

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

Yes.  That's the reason why you can not simply take the first
alternative.  I'm not sure what might be the proper solution here.  It
comes to mind to inject all real packages of an alternatives sequence
(just droping the virtual packages) which is another "interpretation"
of the technical term "alternative" - but tasksel just does not know
such things like alternatives and IMHO it is better to have a bit more
than loosing something.

However, there could be some problem to install one task in case there
might be *conflicting* packages.  So in case we inject "full set of
alternatives" into taskdesc files we either need to query packages table
for conflicts or we might enrich our blends tables in advance with
potentially conflicting packages.  I guess this might be a very rare
case but as always its the single case amongst millions which couses
trouble for the programmer ...

Petter, what do you think?

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

It's nice to have this testcase.

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

Yes.  Usually Petter is very reliable.  If he does not answer he is most
probable on VAC.

Kind regards

        Andreas.

-- 
http://fam-tille.de