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

Hello Andreas,

On Mon, Jul 15, 2013 at 10:07 AM, Andreas Tille <andreas@an3as.eu> wrote:

Hi Emmanouil,

On Fri, Jul 12, 2013 at 07:07:01PM +0300, Emmanouil Kiagias wrote:
> I just committed the new version of {sec-}blend-gen-control which now uses
> the {contain-}provides column.

Great to see the code developing!

:-)

> > flashplugin-nonfree-pulse | libflashsupport,
> 524c525
> < kig,
> ---
> > kig | keuklid | kgeo,

Up to this I admit to say that rather control-sec is correct (see below).

> 553d553
> < libflashsupport,
> 603a604
> > sodipodi,

I do not understand this difference, thought.

If you check above, control-sec contains the full line: flashplugin-nonfree-pulse | libflashsupport

"flashplugin-nonfree-pulse" does not exist at in blends_dependencies table , thus it is not included at all in control. So the latter contains in a single line the libflashsupport(rather than full alternatives relation flashplugin-nonfree-pulse | libflashsupport) and because of the sorting order, flashplugin-nonfree-pulse | libflashsupport entry in the control-sec file is on a different line than the single libflashsupport entry in the control file. Finally sodipodi appears only in control-sec because(same as flashplugin-nonfree-pulse) it does not exist in blends_dependencies(same case as packages: dpt-raidutil,keuklid | kgeo etc).

That's most probably due to the extensive use of alternatives. I simply
injected a new task "alternatives" into the fun Blend which was based on
a copy of debian-edu common task leaving only those Depends + Recommends
that are containing a '|'. (I removed lines matching "Suggests: .*|.*"
because at this moment I assumed suggests are harmless for us - perhaps
it should be reinjected and observed closely as well.) I added a field
"X-Expected-amd64" to each line which is ignored by the Blends tools
(as any field starting with "^X-") but could be helpful for our test suite
(or not - just to bring in an idea).

:-), indeed, it will be helpful to have all the problematic cases in one task file to make tests easier. I will also start using this for debugging.

The problematic
phrase in your arguing is: 'virtual package "nfs-server" is available'.
By definition virtual packages are *not* available - they are just
virtual and need to be provided by a real package.

Yes I know, by definition the way we look up for virtual "availability" is that we check for packages which "provide" the corresponding virtual. So when I write 'virtual package "nfs-server" is available' I mean there are packages available(in a specific arch, release etc) which provide nfs-server. But you are right this sentence as a stand-alone is wrong, anyway I fully understand your argument ;-)

If there is no such
real package the whole set of alternatives should be moved to Suggests.

I did not know about this[0], I will implement that way.

As a consequence of my arguing I thing sec-control is right and control
is wrong ... at least from what I'm reading in your mail. I'd suggest

to put all problematic / interesting cases into the alternatives task of
the fun Blend and by doing so reducing the signal noise ratio around our
problematic cases. Than we can finally discuss these with other people
lurking on this list.

I think I perfectly understood what you mean and I hope I was precise
enough to make my point clear. ;-)

Yes you made your point very clear ;-)

Kind regards

Emmanouil

[0]: http://lintian.debian.org/tags/virtual-package-depends-without-real-package-depends.html