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

[Emmanouil Kiagias <e.kiagias@gmail.com>]

Hello Andreas,

On Tue, Jul 9, 2013 at 3:32 PM, Andreas Tille <andreas@an3as.eu> wrote:

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.

;-), yes that perfectly make sense, especially to obtain blends' set straight from UDD(I don't know why I did not think of this in first place).

 

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.

 Hmm, yes that might be a problem. I checked all the package-differences from debian-edu and debian-imaging. A couple of these packages like djvu-viewer, nfs-server(query all_packages) appear (as you said)  in "provides" column. Also I checked the "apt-cache dump" stdout and there the virtual packages appear as Package: djvu-viewer etc, so they are included(parsed) as normal packages, so for example in the current blend-gen-control the "djvu-viewer" package is available, but in our case it will be missing. What do you suggest doing about this? I will try to think a way to handle these packages. The ideal situation would be to have a separate table(?), generally a  straight forward way to access and fetch info about virtual packages from UDD.

 

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

It's a good idea :-), I will also try to do that.

Kind regards

Emmanouil