Q1:
Hello
When merging 2 constraint lists, what are the rules for merging ?
F.x. if requires foo >=5, foo <7 is in one list that has to be merged with
another list containing conflicts foo <4, foo >=10 ?
Or if the interval boundaries overlap. F.x. requires foo >=5, foo < 7 and
conflicts foo < 3, foo >= 10.
A package should only be mentioned at most once in the resulting list.
In the first case, putting foo >=5,foo < 7 in the resulting list, would mean that requires "beats" conflicts, but I cant see anywhere if this is correct.
And the second case I have no idea how to merge, if a package can only be mentioned once in the constraint list.
A1:
Merging two constraint sets c1 and c2 should return a constraint set c that is the conjunction of the two. That is, a solution should satisfy the constraints in c precisely when it satisfies both c1 and c2. However, if no solution of c could possibly exist, for any database, the merge should simply fail, rather than return an inherently unsatisfiable constraint set.
There are no explicit "conflicts" in a constraint set. For each package name, the interval says what versions of the package may be installed, while the boolean flag additionally says whether the package must be installed. If something is still unclear, please rephrase your question in those terms.
Q2:
Hello,
Following on the last message on "merge", I am confused about the computation on the title (merge (True, 2, 8 ) (False, 4, 6 ) ), since it produces 2 accepted intervals, namely [2, 4) and [6, 8), but the merge function returns only one.
I cannot think of a way to express it, neither as a single "requires" nor a single "conflicts" and merge is supposed to, well, merge them into one.
Is there an assumption that I am missing, or it is up to us the way to handle this special case?
A1:
学生讨论：
(True, 2, 8) and (False, 4, 6) should merge to (True, 4, 6) right?
The left one being equivalent to requires pkg >= 2, pkg < 8
The right one being equivalent to conflicts pkg < 4, pkg >= 6
Right? Or else i think i have misunderstood something.
Which specifically means after merging, versions from 4 to 6 should be ok still, and now required.
老师回答:
The result of the merge should be (True, 4, 6).
Indeed; I assume the example was meant as informal shorthand for, say,
merge [(P “foo”, (True, V [VN 2 “”], V [VN 8 “”]))]
[(P “foo”, (False, V [VN 4 “”], V [VN 6 “”]))]
And correspondingly, the correct output would formally be
Just [(P “foo”, (True, V [VN 4 “”], V [VN 6 “”]))]
In general, both arguments to merge can certainly be lists with more than one element (but each one can have at most one PConstr per package name). Constraints about different package names do not interfere with each other.
Q3：
I have read the problem statement a good amount of times, but I still have some questions:
1) What do you mean exactly with “impose the same net constraints on other packages”? How can two constraints be equivalent while not being exactly the same (or maybe put in different order)?
2) Should normalize “merge” the packages with same names and versions? In other words: are there still supposed to be packages with duplicate names and versions in the output Database?
A3:
1) There are several ways in which constraints can be equivalent without being identical (as Haskell values). A different order is one, as you note; another would be the inclusion of completely non-restrictive constraints like (p, (False, minV, maxV)).
2) Yes, multiple equivalent copies of a specification for a given package name and version should be combined into one, so that the available versions for each package name are listed in strictlydescending order in the output.
再问:
Wrt. 1) what if the restriction is not completely restrictive? E.g if we have the following two package definitions in a database:
package { name foo; version 1; description “The foo application”; requires bar >= 2, bar < 8; }
package { name foo; version 1; description "The foo application"; conflicts bar < 4, bar >= 6; }
From one of the other threads I understand that had this been 1 package definition e.g.: package { name foo; version 1; description “The foo application”; requires bar >= 2, bar < 8; conflicts bar < 2, bar >= 6; }
It should be merged. Is this also the case here? Logically I would think not, as it seems strange to have different constraints for the same pacakge in different repositories, but I would like to make sure.
答：Those two specifications of “foo version 1” are not equivalent: the first one requires bar to also be installed, while the second one does not. So if both are present in a database, that’s a definite inconsistency, and normalize should indeed report an error.