|
2
by Robert Collins
Create MissingConflictFinder class and tests for getting possible |
1 |
* consult launchpad publishing records to decide what missing conflicts |
2 |
are still relevant. A missing conflict rule in a non published package |
|
3 |
is not relevant; a missing conflict in a published package with a non |
|
4 |
published package is relevant. |
|
5 |
this can be inferred reasonably reliable by using the all_packages members |
|
6 |
as the 'published' versions : any conflict that does not involve one |
|
7 |
member of the current all packages dictionary is not interesting. |
|
8 |
* Make this code able to be run quickly, incrementally, as a check during |
|
9 |
publishing. An upload that introduces a new conflict bug can be rejected. |
|
10 |
||
11 |
order of processing: |
|
12 |
1) get all active packages |
|
13 |
2) pull said package files and insert into database |
|
14 |
3) TODO if the list of files [which intersect other packages] and the |
|
15 |
conflicts/replaces/provides entries are unchanged, just adjust the version |
|
16 |
it is replacing's entries. |
|
17 |
3) for each conflicting file (can optimise later, to gather a group of |
|
18 |
identical conflicts on a set of files): |
|
19 |
3a) generate a list of all pairs involving any published package on the |
|
20 |
left and any package, published or not, on the right. |
|
21 |
3b) for each of these pairs check whether the conflicts relation is satisified |
|
22 |
(stop here), or the replaces relation is satisfied (stop here, it was an |
|
23 |
upgrade). |
|
24 |
if neither of these are satisfied, then a bug is present. |
|
|
12
by Robert Collins
Notes on persistence |
25 |
|
26 |
conflicts <= always wrong (, conflicts > always wrong (not supported) |