Hi, Quoting Hector Oron (2015-08-28 15:44:58) > 2015-08-28 14:53 GMT+02:00 Johannes Schauer <josch@debian.org>: > > since multiple packages are able to provide the same package name and since > > there are dependency alternatives (A|B), there exist multiple solutions for > > most dependency satisfaction questions. If all constraints are honored then > > they are all correct. > > Right! Currently we, officially use different solvers... on server > side, dose3 is run to check package instalability (which needs to be > optimizaed to take less time on its calculations - as you are already aware > of by reading IRC backlog). can you open a thread or bug about this problem in a separate thread? I must admit I am not frequenting the IRC channel often enough and I'd like to have all information I need to tackle this problem in an archived place like a mailing list or bug report. > On build daemon side, solver calculations are deferred to sbuild, which > allows different solvers, in non-experimental case, apt solver is used; for > experimental case, aptitude solver is used. One of the problems we have is > that dose3 and sbuild problem solving differs, it'd be nice to produce same > results both sides. Why? As far as I understand you are not interested in all which solution dose3 gives you. You are only interested in whether a solution exists or not. The answer you want from dose3 is a binary one and not a package set. The assumption then is, that if there exists a solution, then another solver will be able to find it too. Unfortunately neither apt nor aptitude are by itself real SAT solvers, so there will be situations where dose3 finds a solution but apt and aptitude do not. I don't think you want to find a way to somehow tell sbuild about the solution dose3 found. > Not sure if dropping B from (A|B) style dependencies might help, as I > understood that's already the case for sbuild. You are only thinking of direct dependencies. But there are transitive dependencies too, and A|B style dependencies can happen anywhere in the dependency tree. > > The bug you quote mentions "bogus" packages drawn in by aptitude. Either > > aptitude is not respecting build and binary dependencies correctly in which > > case, these packages are indeed "bogus" (but then this is an aptitude bug), > > or the metadata is incorrectly expressing that these extra packages can be > > part of the solution. > > > > Which of these problems are you concerned about? > > On the linked bug report, Sune was apparently worried that solver was > pulling more packages than really needed. I suspect that matches your > first case. Maybe. I'm not familiar with aptitude or in which case it might not respect build and binary dependencies correctly. > > As with this specific "bogus" package problem, aspcud "should" not have > > this problem because it optimizes the solution by the given optimization > > criterea. As far as this optimization criterea is concerned there is no > > "bogus" packages (if we assume that there is no bug in aspcud). In that > > case, are you concerned about the right optimization criterea? Or about > > dependency relationships that could lead to solutions that you might call > > "bogus"? Or about a bug in aspcud? > > I would be mainly worried by the case of server calculations (dose3) > not matching build daemon calculations (sbuild, apt or aptitude). And by "not matching" you mean the installation set not matching or the binary conclusion whether or not the source package dependencies are installable or not matching? If the former, then you will be very disappointed by the dependency sets chosen by dose3. In contrast to apt and aspcud, if you ask dose3 for an installation set, then it will give you a valid one but it will not be optimized in any particular way. With apt for example you can for example at least trust that if you have a dependency A|B, then A will be chosen (if it is installable). But dose3 treats A|B as equal to B|A and will thus often produce installation sets you really don't want. This is not a problem though because you want to use dose3 for the binary decision whether or not source package dependencies are satisfiable or not. If you want to choose a "good" installation set, then you either rely on the heuristics built into apt, tweak the heuristics that aptitude allows you to tweak, or create a optimization criteria that aspcud will then give you a truly minimal solution for. > > It is extremely hard to compare solutions because in most cases, the > > solution found by apt will be different from the one found by aptitude or > > dose3. > > Exactly! That's probably my main concern, it'd be great to standarize > on one single solver to rule them all. You probably mean a solver for the purpose of installing build dependencies in a clean chroot only, because in the general case one will be hard pressed to find a solver to "rule them all". If you mean a solver to rule all build dependency installations in clean chroots then I agree with you. It would be great if package builds could truly be reproduced this way on any platform by anyone. > > Would it be sufficient for you if I picked a snapshot, rebuilt all packages > > in experimental with the apt resolver and then rebuild those that fail with > > apt with the aptitude as well as with the aspcud resolver and then compare > > the results from the aptitude to the aspcud resolver? And by compare I > > mean: make sure that there is no FTBFS with the aspcud resolver where there > > is none with the aptitude resolver? > > Not sure if sufficient, but at least it is interesting test case to check. If you want something else to be checked, please speak up. Right now I am not sure what checks would make you happy. > I would also like PPA-like (bikesheds) scenario to be tested, even the case > of multiple chained PPA-likes, but I do not think we currently have real > data. Also considering Haskell packages as initial set sounds good to me, as > those have quite tight versioned dependencies having extremely long > dependency resolution chain which exposes aptitude solver bug. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature