Hello Andreas,
On Mon, Jul 15, 2013 at 10:07 AM, Andreas Tille <[email protected]> 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. > > Ok > 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
