Hello Andreas,
On Tue, Jul 9, 2013 at 3:32 PM, Andreas Tille <[email protected]> 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
