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

[Andreas Tille <andreas@an3as.eu>]

Hi Emmanouil,

On Wed, Jun 26, 2013 at 09:04:25PM +0300, Emmanouil Kiagias wrote:
> [sending this message to the list, I accidentally sent it private ]
> 
> Hello Andreas,
> 
> I just committed to git a first version of blend-gen-control. This time it
> is able to also generates the task-description file. The command line
> arguments are more or less the same with the current's blend-gen-control.
> 
> Generally i tried to imitate the current's blend-gen-control functionality
> (eg I also included the nodepends and suppressempty flags and the hasconfig
> variable).

I called blend-gen-control but can not find any output.

> If no architecture is provided as a command line argument it works as we
> discussed, it generates a control(or a task description) file of each
> available Debian architecture: <filename>.<arch>. For the moment the
> generated files are saved locally under the control/ or taskdesc/ folders
> in the blends-gsoc project folder

Both dirs just contain a readme file.

> I have not really made any proper testing for the moment but this is my
> next plan, still long way to go :-).(at first sight the files' syntax seems
> to be ok and the packages are printed the same way they are taken from UDD,
> so at least it seems to walk in the right way).
> 
> Here are some notes about the new code:
> * generally the 'debug" messages are not so *convincing* (i am not quite
> sure if they help in case something strange happens) so I will try to fix
> that while I am testing.
> 
> * in order to get the Priority, Section, Enhances (if any) fields for the
> tasks I am using UDD table "packages" (full outer join the blends_tasks
> with the packages) (for example you can check the sql  statement in the
> script in blends-gsoc/sql/taskinfo)

The idea to queery the packages table seems to be clever at first sight
but finally this is a "circular dependency".  Blend-gen-control is used
to create metapackages and these will be uploaded to Debian and from
there the information ends up in the packages table.  So on one hand you
have no chance to change these metadata nor do you get anything for new
packages.  So we need to find a different solution:  For the moment this
is very simple:  We just fix the values:

   Priority: extra
   Section: misc

The later is debatable but for the moment it would work.  Perhaps we
need to add a Section field directly into the tasks files to get better
control over this value (and move this metadate to the blends_metadata
table).  As far as I see it currently "Priority: extra" is the way to go
for metapackages.  This was discussed previously and we just can leave
it as is.

> * In the current blend-gen-control in the "print_task_desc" function,
> inside the if-clause where you check if the current task in the loop if it
> haspackages and if the suppressempty flag in enable (lines 251-268) you
> check for a header "Test-always-lang". Do we have to handle something like
> that in the new blend-gen-control?(for the moment there is no such field in
> the the blends_tasks so I have not add anything similar to the code).

I think we need to make sure that *every* information will propagate
into UDD.  If you are interested you can perfectly try to dive into
this.  It is

    git://git.debian.org/git/collab-qa/udd.git

and you need to redefine the table columns (see dir sql/) and adapt
udd/blends_metadata_gatherer.py to read in the data.

> * In the blend_dependencies UDD table we can not disguise the alternative
> packages (eg package1 | package 2) so for the moment in my gen_task_desc
> function, which generates the task description file, I am printing/saving
> all the depends and recommends packages(i do not know if this is correct),
> current blend-gen-control takes the first which is available (of the
> alternatives). I need to check again that.

You are perfectly right that this is a flaw inside the Blends table
structure.  The reason for this is that when I wrote this code I did not
hat the metapackage creation in mind but rather the pure set of packages
involved.  I have no really good suggestion whet to do here.  I'll try to
think about this - suggestions welcome.

> * finally I need to remove some code redundancy, the taskinfo(meaning the
> task title, description, blends_tasks fields) stays the same between
> architectures but in the current loop which generates multiple files(each
> per arch) this same query(about the task info) is getting executed multiple
> times(I will soon write it in a more clever way)

OK.

> Also about the control file syntax discussion we had, I sent(you have
> probably already seen it) a mail[0] to debian-blends@lists.debian.org as
> you proposed. I am not sure if I used the proper words to describe the
> question :-) .

You probably mean debian-mentors and yes, I'm reading this list.  Let's
wait for another 24h and lets see if wee need to find another wording.

> Any feedback or any hints/ideas are always more than welcome :-)

As said above: I can not see any output in control/ of taskdesc/.  Any
idea what might be wrong?

Kind regards

        Andreas.


-- 
http://fam-tille.de