Hi, On Fri, Oct 30, 2015 at 01:33:59PM +0100, Johannes Schauer wrote: > then the resulting /tmp/dump.edsp does not contain any such field and > thus the solver is not told which version of ghc to install. I think you mean the flag is on the wrong stanza, as I have it, just on the stanza which is the candidate based on pin-value aka 7.8.4-9 for me. > Please make it so that specifying ghc=7.10.2-2 or ghc/experimental on > the apt command line both mark the right package stanza in the EDSP > output with APT-Candidate:Yes. The "fun" in this bug is that a while ago we discussed on #debian-apt the shitty API used to get 'the' candidate of a package as there are very similar methods (distributed over different classes) doing roughly the same expect that one gives the candidate before reading preferences files, another after and the last one with commandline and stuff added in which is usually regarded as "the candidate" and 99,999% of the time what you want, just that the other two exist as well and usually produce the correct candidate for most of the packages… so, while we all agreed on disliking this no action was triggered as thats hard and stuff (the method with the most logic interface is marked inline and is number 2, which is in fact a shorthand for the real 2 conveniently hiding the class name which would give away that it is in fact 2 and instead makes it appear like its 3. As said: Great API!) So, with this background information, guess what is wrong with the EDSP generation… "someone" (aka: me) picked the method 2 thinking it was 3. So, the obvious patch is what Julian has written in the meantime, while I was throwing a tantrum. (btw: I hope that the diff shows what I meant with most logic interface) For me, that is the straw that broke the camel's back. I was halfway through rage-changing GetCandidateVer to do the right thing, before I came to the conclusion that it will make more sense to add a 4th method: GetCandidateVersion, simply because there is already a SetCandidateVersion and even through codesearch suggests there aren't an awful lot of users and I doubt it would turn out worse for them, instead of officially breaking the API lets just deprecate 2 and have 4 (which looks like 2) be a wrapper for 3. Yeah for API design! Best regards David Kalnischkies P.S.: Based on codesearch, it looks like the maintainers of the API are the only folks which make this mistake. Multiple times. For generations.
Attachment:
signature.asc
Description: PGP signature