~sbeattie/conflictchecker/conflictchecker-fixups

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
* consult launchpad publishing records to decide what missing conflicts
are still relevant. A missing conflict rule in a non published package
is not relevant; a missing conflict in a published package with a non
published package is relevant.
this can be inferred reasonably reliable by using the all_packages members
as the 'published' versions : any conflict that does not involve one
member of the current all packages dictionary is not interesting. 
* Make this code able to be run quickly, incrementally, as a check during
publishing. An upload that introduces a new conflict bug can be rejected.

order of processing:
 1) get all active packages
 2) pull said package files and insert into database
 3) TODO if the list of files [which intersect other packages] and the 
    conflicts/replaces/provides entries are unchanged, just adjust the version
    it is replacing's entries.
 3) for each conflicting file (can optimise later, to gather a group of
    identical conflicts on a set of files):
 3a) generate a list of all pairs involving any published package on the
    left and any package, published or not, on the right.
 3b) for each of these pairs check whether the conflicts relation is satisified
    (stop here), or the replaces relation is satisfied (stop here, it was an
    upgrade).
    if neither of these are satisfied, then a bug is present. 

conflicts <= always wrong (, conflicts > always wrong (not supported)