[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SAT based britney


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

The complete solution would involve separate logical atoms for migrating
a package (foo_1234/testing) and for checking installability
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

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.


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

Reply to: