Re: SAT based britney - handling conflicts
Hi,
On Wed, 29 Jun 2011, Ralf Treinen wrote:
> > 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 might not be perfect, but IMO it's not a bad rule. When a file is
moved, you really want to upgrade both sides at the same time if you have
both installed. And this even if there's no other package that requires
both packages to be installed at the same time.
And the same logic holds with Breaks imo.
> 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,
This is something we can and should detect indeed.
> 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.
Expressed that way it seems stronger than what I said, but it might just
be an impression.
> 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:
I'm happy to consider disjunctive dependencies like conjunctive ones
for the specific purpose of deciding whether a given package depends both
on A and B. If the only result is that we force the migration of 2
packages together that might not have required it, it's not big deal IMO.
> > 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 :-)
You could but I doubt we have such trivial cases. We could also review
all the dependencies on real packages that provide & conflict on a virtual
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.
Much like some "upgrade hints" could be helpful (i.e. a way to formalise
the expected result on other packages).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: