Hallo, Am Montag, den 16.05.2011, 20:17 +0200 schrieb Julien Cristau: > On Mon, May 16, 2011 at 19:03:35 +0530, Joachim Breitner wrote: > > Am Montag, den 16.05.2011, 11:44 +0200 schrieb Raphael Hertzog: > > > On Sun, 15 May 2011, Joachim Breitner wrote: > > > > And in > > > > the absence of conflicts, this means that A and B are co-installable. > > > > > > Yes, but what about this, T is the package we're considering to migrate. > > > > > > T depends on A, B > > > A depends on D1 | D2 > > > B depends on D2 | D3 > > > D1 conflicts with D3 > > > D2 is not satisfiable/installable in testing (but is in unstable) > > > D1 is installable alone in testing > > > D3 is installable alone in testing > > > There is a conflict, so I’m not claiming to handle this perfectly. I > > hope such cases are rare. And note that my system allows for manual > > addition of rules, so if we come across situations that are treated > > insufficiently, and such situations are rare enough, additional > > constraints can be added by the RM team. E.g. in this case, after some > > thought, the additional constraint "T implies D2" should be sufficient. > > > Not sure I'd want to replace one manual task (adding hints for packages > which need to migrate together) with another (handling conflicts). I > have no precise idea how common that situation is; I fear it's more > common than you seem to think. > > I like the part where we wouldn't have to keep maintaining much of this > code though... If cases where a conflict (of the non-versioned-kind, i.e. a conflict only with regard to installability and not with regard to presence in an suite) has an effect on the migrateability occur often, then this poses indeed a serious problem. Can we still somehow map this to a SAT problem? The complete solution would involve separate logical atoms for migrating a package (foo_1234/testing) and for checking installability (foo_1234/testing/installable_for_foo_1234, bar_987/testing/installable_for_foo_1234). But for the installability of each package, the installability of the dependencies have to be solved independed, causing a quadratic explosion of atoms. Clearly not possible. Back to the concrete example: Maybe the situation should be manually detected _once_ and then handled by asking T to depend on D2 (after all, T will not be installable without D2). Or, if this is not something you want to impose on the maintainer, some kind of permanent overwrite could be passed to SAT-britney with the same effect. Still, every case needs to be handled manually, but at least only once. But it’s up to you (as in the release team) to decide what you’d rather do: Figure out conflict problems manually (or just let them migrate to testing and handle them later), or write hints for large transition. Greetings, 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