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

[Andreas Tille <andreas@an3as.eu>]

Hi,

On Thu, Jun 27, 2013 at 04:54:30PM +0300, Emmanouil Kiagias wrote:
> > Ahhh - sure.  This is what we agreed upon.  I'd call it a useful feature
> > if either -c or -t would be a required option.  Otherwise it is
> > confusing if the script needs some time ... to do nothing.
> >
> 
> Ok I fixed this (so now either -c or -t are required or the script will
> dump an error message)

Thanks.

> > But in the new output it is always only 'med'
> >
> Yes you right, I forgot to do the right "format" in python,I fixed it, I
> think now it should be ok.
> 
> Note: I have made a git commit yet so the fixes are not there

OK.  I'll watch the commit list anyway.

> Ok for the moment I will provide fixed values:
> 
> Priority : extra
> Section : misc

This will do for the moment.  (But see below)

> Most of the Blends do not provide a Section field(optional as you said) so
> we can leave it empty for those it but in cases they provide it (like some
> task in education blend) ,as you said, we can override the default(or the
> null value) and add it to the generated files.

Ahhh - seems I totally ignored this all the time.  The Section field is
totally ignored inside the docs because I never realised that it is
actually used.  This pushes the issue a bit higher on my todo list (for
doc and UDD importer).  But once the Section will be in UDD it is surely
a very quick hack for you to add the Section to the output.  Thanks for
pointing me to the Debian Edu tasks.

> Also I forgot to mention that yesterday: I think we also need to save the
> "Leaf" field for the tasks, because in the task description file we do not
> print out the tasks which have the Leaf : false. For example the education
> blend tasks : chemistry, common, electronics etc have a field Leaf : false
> and thus they are not included in the task-description file. Without this
> field my code can not disguise the non leaf tasks so for the moment it
> dumps everything(which I do not think its correct). Also the same goes for
> the field/header : Test-always-lang(as we discussed in the previous mail).

Note for my-TODO list:
   Add fields:
        Section
        Enhances
        Leaf
        Test-always-lang
   to UDD importer and Blends doc.

> > And as you said
> | I think we need to make sure that *every* information will propagate into
> > UDD
> 
> Yes I also agree. A first quick(and little dirty) solution it can be to add
> these extra fields (Leaf etc) in the blends_tasks and for those tasks which
> do not provide them can be left NULL in the UDD. The problem with this
> solution is that these extra  fields( mandatory if they exist) are not
> represented by the majority of the Blends(most of their tasks do not
> include them). So another better solution (a quick idea) can be the
> following:
> 
> In order not to spoil the blends_tasks UDD table(its fields are fine cause
> all blends' task provide these info) we can have an extra table  for
> example with the blends_tasks_extra(or whatever sounds better) with the
> following fields:
> 
> table: blends_tasks_extra :
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - -
> Task(primary key)    |      field(or header)      |      value
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> lang-de                  |     Test-always-lang     |      de
> chemistry               |            Leaf               |     false
> .....
> 
> That way we can get from UDD any extra fields a task might contain and
> might be needed for the control/task-description files, without changing
> any sql in case we need an extra field, we just add a new row in the table
> with the field we might want/need.

I agree that this would work as well but it somehow spoils the
systematic of the UDD importer.  Usually UDD follows a principle of not
normalised tables featuring several rows.  I do not see any point in
breaking this principle for no visible gain.

> So here we can also add the Section field(if any) or the Enhances(some
> tasks also provides this field) etc.
> This just a first idea, I take some time these days to think of this again.

If you agree to my arguing I could simply implement what was written
above for my TODO-list.

> > I guess it even goes into the direction of an additional table.  I do not
> > see a good way to squeeze the packages that are interesting for a Blend and
> > the alternatives inbetween these packages into one table.
> >
> >
> Yes I totally agree with this. A first idea can be the following:
> 
> While we parse the package dependecies from the tasks files to fill in the
> blend_dependencies table when we come across a package:
> 
> Depends: package1 | package2 | package3
> 
> We only add the *first* package in blends_dependencies(in our case will be
> the package1). And then we add the rest in an extra table:
> 
> table: blends_dependencies_altervatives(or something like that)
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> package (primary key)       |    alternative
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> package1                        |     package2
> package1                        |     package3
> ....
> 
> That way for each package in the blend_dependencies we can find its
> alternatives and construct again the  package1 | package2 | package3 (which
> can go as is in the control file) and also for the task-description file we
> take the first available etc.
> 
> This is also a first idea, I will think of it again and try to come back
> with a solid(maybe better) plan about these issues.

I somehow have the feeling that this might be a bit weak because there
might be other occurences where package1 should be not feature other
packages as alternatives but they should be added explicitly for
whatever reason.  I'm tempted to just throw into the table what is found
between the ',' in a Depends line.  I'll keep on thinking about this,
thought.

> Regarding the udd/blends_metadata_gathener.py and generally the udd/sql I
> would be happy to write patches for the new ideas/changes as soon as we
> agree on a solution or when we start testing(the next couple of days) :-)

:-)

It definitely will not harm if you read a bit in the sources.

Kind regards

      Andreas.

-- 
http://fam-tille.de