Heya, On Tue, Nov 19, 2013 at 12:55:40AM +0100, David Kalnischkies wrote: > > More generally, the problem is one we've debated before and for > > which I think we don't have (yet?) a decent solution: there is no > > first-class notion of "user specification" in the APT code > > base. Once the command line is interpreted, it gets "compiled" to > > pin values, and it's subsequently hard to distinguish what the user > > requested right now, as opposed to other inherited pin values. > > It's "worse"; it's changing the candidate directly, not fiddling with > pin at all, but that just as a sidenote. This is a legitimate concern but it's one that, AFAICT, we have both faced and addressed already. In response to this concern we introduced the APT::Solver::Strict-Pinning configuration setting. As long as that settings remains to its default value (= "yes"), pinning is strictly enforced by the solver, to the point that only candidates are fed to it: the solver it's not even aware that non candidate package versions exist. None of the patches we're discussing here (nor other changes in the apt-cudf toolchain that I'm aware of) changes that. So, whereas it is true that the solver *can* change the candidate, that will happen only if the user has explicitly stated something like "please consider my pin settings only as a hint, and not as a strict constraint". That "risk" was already on the table before these patches, and AFAICT is unchanged by them. Is this enough to appease the concern? Note: in the above I've treated uniformly the packages specified on the command line and their dependencies. I understand you're making a distinction among them, and in particular on how "binding" we should consider user specifications on them. If we want to add an extra level of flexibility there---i.e. enable users to independently specific strict pinnings for the two cases---it can certainly be done, but this seems to be a separate matter. > My main problem with it is that the resolver should not try to > understand what the user wants, that is the task of the front-end > feeding the solver with the problem to solve. If the solver can't > satisfy the request it should fail and the front-end refines (maybe > with the user) the request for another try rather than letting the > solver relax some requirements all by itself. I agree that the frontend should be in charge here. But, as a matter of fact, we don't have this ping-pong functionality in any frontend (yet?). Also, if we assume that frontends *will* be in charge, I don't see where is the problem in giving the solvers more freedom. For instance, we can expect solvers to return packages other then candidates if there is no other solution available, and then expect frontends to spot that the chosen versions are not the candidates and notify the users of the "problem". In that case, if the user agrees to go on, we already have the alternative solution available, without having to invoke the solver multiple times. (And, again, if frontends do not want this to happen, it is enough to leave StrictPinning unchanged, that way they have the guarantee that the proposed solution will be a subset of candidate versions.) > The more obvious examples in which 'foo' changes the meaning between > versions (think: chromium, git) are not that common, but they are the > extreme values of changes between versions, but even the small changes > in between versions can matter… (oh, you meant to upgrade to the > security bugfix in 1-3? I thought 1-2 was good enough for you…) Right. I think that the chromium/git example is basically unsolvable, because it messes up our package namespace, and on its unicity a lot of our current procedures and work-flow are based. They are exceptions, fortunately rare enough, and they should be treated as such, IMHO. The security bugfix example is more interesting. My take on it is that we should have metadata about all the aspects on which users might want to base their version selection, including bugs, and made the solvers aware of them. Once that happens, we then have all the needed expressivity to request to the solvers criteria like "only give me solutions where all security bugs are marked as fixed". In the (possibly long, granted) interim where this is not possible, just don't fiddle with StrictPinning :-) Cheers. -- Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature