Hi, Am Freitag, den 13.05.2011, 22:17 +0200 schrieb Raphael Hertzog: > On Wed, 11 May 2011, Joachim Breitner wrote: > > * Do you think it can handle all current and anticipatable > > requirements? (I’m not involved in release team work and might missed > > some conditions.) > > You mention that the tool can't deal properly with Conflicts for ensuring > installability. I wonder if there aren't more similar problems related > to this requirement of keeping package installable. > > For instance, I wonder how you'd deal with alternative dependencies? I can > imagine that you can find out solutions where each package can be > individually installed but where both sets of dependencies are not > co-installable (in particular if you solve some dependencies with > different versions of the same binary package, and here Conflicts is not > involved). No, that should be no problem. Versioned constraints are resolved precisely to the list of existing concrete packages which fulfill the requirement before the resulting constraint being passed to the SAT-solver, so no irregularities there. As long as the invariant that for each binary package, there is exactly one version in testing, is not overwritten manually then the migratability of A and B means A is installable and B is installable using the same set of packages. And in the absence of conflicts, this means that A and B are co-installable. > > * What do you think of the advantages and improvements that I point > > out? > > To me it looks great but I have no experience with SAT solver and I > wonder whether the sheer amount of predicates that it will have to handle > will not result in something dog-slow. That is indeed a problem. I have heard impressive results for todays SAT-solvers (given the NP-hardness of the problem), but it is hard to predict for me. I’d say that given the reduced number of Conflicts (which make things harder) there is a chance that it will not take longer than a full edos-distcheck run. > > The system is three-layered. On the lowest level is a general purpose > > MAX-SAT-solver. It takes as input a propositional formula in conjunctive > > normal form with some variables, and a list of “desired” variables. It > > Presented that way, it corresponds exactly to what is needed to implement > the rolling distributions described in > http://lists.debian.org/debian-devel/2011/05/msg00275.html > > Maybe it can be a good testbed for the concept. Yes, I had things like this in mind. Also, it should be able to handle multi-way-transitions between several suits (unstable/testing/cut/volatile/stable-updates) with invariants that should hold across different suites (e.g. a package in cut may not be older than the one in testing) in one run. That is why I have added the suffix /testing in the proposed syntax. > > * a satisfying assignment which is maximal, i.e. there is no satisfying > > assignment where a strict superset of desired variables is true. > > FWIW, Britney tries to migrate packages one by one, starting with the most > important packages. It doesn't consider them all together. ...which makes life hard for the release-team with transitions such as Haskell, where >200 source packages have to migrate at once, right? > britney generates a Heidi file. It has this format: > <package> <version> <architecture> > > <architecture> can also have the special value "source" for the source > package. The heidi file is then fed to "dak control-suite". Great, looks almost like the atoms I proposed. So from a satisfying assignment generating this is trivial. > > So here is my heuristic to handle this: If a Conflicts or Breaks has an > > upper version constraint, then add a corresponding clause. If not, > > ignore it. > > > > This might lead to uninstallable packages in testing in corner cases > > (imagine some package depending on both exim4 and postfix), but such a > > case is clearly an RC bug that ought to be filed by someone and which > > would be detected by a run of edos-distcheck on unstable already. > > I think it's more likely that such problems happen with conflicting > dependencies further down in the dependency tree (i.e. not directly on the > same package). Sure, but it would still be uncovered easily by edos-distcheck on unstable or testing, and subsequently be fixed like any other RC bug. (I know this is a weakness of the proposal, so I’m arguing hard that the weakness is not too serious :-)) > > PS: Please give honest feedback. I’d rather been told that this is > > rubbish and not spend time on it than spending time on it and afterwards > > noticing that it will not be used. > > Remember my feedback is one of an (interested) outsider, I have almost no > experience feeding hints to britney. Nevertheless, thanks for the feedback! Greetings from Manali, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part