Re: SAT based britney - handling conflicts
Hi,
On Thu, Jun 23, 2011 at 10:25:55AM +0200, Raphael Hertzog wrote:
> You're suggesting that one way to legitimately ignore the problem of
> Conflicts would be to have the Debian policy only allow usage of Conflicts
> for cases that cannot create problems during testing migration. Is that
> right ?
This is one reason, but it would also work the other way round: if we
had a way to say that certain kinds of conflicts between packages must
not occur then we should put it into policy so that we have a precise
rule for telling problematic packages (in case the criterion is
certain), or at least implement some check, using the edos tools for
instance, to get a list of problematic cases that then can be
investigated by hand.
> I'm not sure how you can formally define whether a Conflicts is likely to
> create migrations problems or not.
I don't know either ATM how to do it. Anyway, your classification
below helps a lot in this discussion:
> However we know the common use cases for Conflicts and it seems to me that
> they are ok:
>
> 1/ conflict for files that have moved within binary packages of the same
> source, policy requires the conflicts/breaks to be versionned, and the
> simple rule that requires all the binary packages of the source to
> be moved together makes it moot
Agreed.
> 2/ conflicts for files that have moved between binary packages of
> different sources, policy requires the conflicts/breaks to be
> versionned, and the problem can be solved prior to the definition of
> the SAT problem by adding a supplementary rule that forces the upgrade
> of both source packages together
I see two problems here:
1) lets call A and B the two binary packages between whom the file was
moved. Why should we add a constraint that A and B must migrate
together? Maybe A is not ready to migrate for any other reason, so
this would stop B from migrating. It is true that migrating B without
migrating A would create a conflict in testing between A and B, but
maybe this conflict was already there before, or maybe this new
conflict is nothing we should worry about. I think that in general it
would be much too restrictive to require that, if a set {A,B,C} was
installable together before the migration, then the same should hold
after the migration.
One way of approaching this question is: we should put a requirement
that A and B must migrate together only in case there is a third
package, say C, that depends both on A and B.
2) However, this leads us to another problem that is related to an
example by Raphael early in this thread (this was the example with
disjunctive dependendencies in [1]): It is not so clear what it means
for a package to depend on another package since dependencies possibly
are not local to the package (like: C declares directly a dependency
on A and B) but may be indirect, like in any of the following
situations:
example a) Here, C logically depends on A and B, but this seen only
when following dependency chains:
Package: C
Depends: E, F
Package: E
Depends: A
Package: F
Depends: B
Package: A
Conflicts B
example b) Here, C logically depends on A and B, despite the fact that
there is a disjunction involved. This is due to the fact that one
of the branches of the disjunction, that is G, is invalidated.
Package: C
Depends: E, F|G
Package: E
Depends: A
Package: F
Depends: B
Package: G
Conflicts: A
Package: B
Conflicts: A
For added fun, in any of the two examples the dependency from E to A may
exist only in testing and not in unstable, or the other way round. That is,
dependencies between packages may be indirect (we call these "strong
dependencies" [2]). In this case they are relative to the repository,
and not an isolated property of the package alone.
> 3/ permanent conflict for a service provided, the various conflicting
> packages are usually alternatives in dependencies (via virtual
> packages) and as such there's very few dependency trees that would
> force to have two conflicting packages together
This is interesting. If we had a way of distinguishing this case 3/
from 4/ below then we could implement a check of the archive that
detects whether some package strongly depends (in the above sense) on
two packages that are in a type-3 conflict. One special case would be
relatively easy to detect: C strongly depends on A,B, and both A and B
do a "provides: v" and "conflicts: v". Maybe we should add this check to
edos.debian.net :-)
> 4/ permament conflict for a random file conflict that has not yet been
> solved by renaming one side. This should be temporary.
On Thu, Jun 23, 2011 at 01:06:44PM +0200, Joachim Breitner wrote:
> A clean solution would be to require package maintainers to be specific
> in their Conflicts, and have different fields for „This package should
> generally not be installed along the other package.“ and „There is
> something temporary wrong with the combination of this package and the
> other package (usually with some version constarint) so that a release
> should not contain this and the other package“.
Yes, indeed, it would be very useful to have this kind of justification
of a conflict. IMHO one can say that almost always dependencies are from
upstream and conflicts are from the package maintainer, so (s)he should
be able to give such a justification. A machine-readable format for this
would be extra good.
Cheers -Zack and Ralf
[1] <1305552815.2280.50.camel@kirk>
[2] http://www.mancoosi.org/papers/esem-2009.pdf
--
Ralf Treinen
Laboratoire Preuves, Programmes et Systèmes
Université Paris Diderot, Paris, France.
http://www.pps.jussieu.fr/~treinen/
Reply to: