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

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

Hi Emmanouil,

On Mon, Jul 08, 2013 at 11:02:04PM +0300, Emmanouil Kiagias wrote:
> Hello Andreas,
> I just committed a simple script by the name "tester". As I write in the
> commit log:
> ...generates control/task-description files for all Blends and compares the
> generated files, needs no arguments to be executed, usage: ./tester

Cool.  I also though about creating some kind of test-suite when I went
offline yesterday after reading your last mail.  This perfectly fits!

I pushed two sligth changes to make the tester less noisy (if $DEBUG is
not set) to make sure I will not miss any diff output.  The other change
affects the set of Blends which are regarded:  IMHO it is just safer to
obtain this set directly from UDD.

> By running the tester script both ways seem to generate same files for all
> Blends except from the debian-edu control files(the data differences
>  between blends_dependencies and blends_dependencies_alternatives table as
> I mentioned in a previous mail ) and debian-imaging as shown below(data
> differences between tables):

What I'm really wondering regarding these differences is, whether
possibly the UDD content in some aspect might be "wrong" ... in other
words not fit for our purpose.

> #for debian-imaging
> Comparing control/control.amd64 with control-sec/control.amd64
> 63c63
> < Suggests: djview4 | djview3
> ---
> > Suggests: djview4 | djview3 | djvu-viewer
> #So here we have
> #exists:
> select blend, task, alternatives, component, distribution, dependency from
> blends_dependencies_alternatives where alternatives like '%djvu-viewer%';
> #does not exist
> select blend, task, package, component, distribution, dependency from
> blends_dependencies where package='djvu-viewer';

Hmmm, I admit I do not fully understand this but it seems to concern
pure virtual packages.  It might possibly be a good idea to somehow look
up the 'provides' column inside the 'packages' table.  I need to check
this more detailed.

> Apart from this the rest of the generated files seem to be the same for
> both {sec-}blend-gen-control scripts.

Regarding the test case I had in mind putting all "critical" entries
from tester into a common task inside the fun Blend (feel free to create
a new task there - it is "just for debugging fun" and should never be
released).  This should be safe against random changes of the tasks
content (or if something is changed we could adapt the test) and thus
the test will not be spoiled by some random commit of a Blends

Kind regards



Reply to: