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

[Andreas Tille <andreas@an3as.eu>]

Hi,

On Tue, Jul 09, 2013 at 09:24:22PM +0300, Emmanouil Kiagias 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).

... because you simply go the same route as I did (unobserved by others
;-)).

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

As I said I have not fully understood the problem and I need to spend
some more time into this.  However, my feeling says we should not go
with a separate table but rather with an additional column.  Something
like 'contains_provides' 0 / 1 or something like this.  This could be
checked inside the blends-metadata importer.

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

       Andreas.

-- 
http://fam-tille.de