Re: [UPLOADED] RFC: The Future of Solving Dependency Problems in APT (SAT, CUDF)
On Do, 2010-12-30 at 09:26 +0100, Stefano Zacchiroli wrote:
> On Tue, Dec 28, 2010 at 03:47:22PM +0100, Julian Andres Klode wrote:
> > Not really, you can declare literals more or less important than
> > others which deals with almost every case I throw at it.
> >
> > /* Keep manually installed packages or installed packages that are
> > * candidates on the system and non-candidates away if possible. */
> > if (is_installed && (!is_automatic || cand == ver))
> > picosat_set_more_important_lit(var(ver));
> > else if (!is_installed && cand != ver)
> > picosat_set_more_important_lit(var(ver));
>
> Problem is: by doing this, you're now adding quite some implicit
> requirements not only on a SAT solver (which is just one among several
> possible solving techniques), but also on a solver that supports an
> interface like the above. The possibility of changing the solver
> according to a standardized interface of the user is, if not
> jeopardized, significantly diminished.
I don't see why. I just tell the solver to respect the policy and do the
expected thing. Without it, it does too much non-sense. Perhaps we could
introduce APT::Solver::Policy with values like "paranoid" and "trendy".
Currently, the solver tends to go more into the "paranoid" direction.
>
> > The solver will first try to solve the problems by setting
> > non-candidate versions to -1 and installed versions (manually
> > installed or candidates) to 1 and then trying other solutions.
>
> It sounds like it will explode pretty soon. Have you tried running it
> with several suites (e.g. stable+testing+unstable) trying to install
> packages from the non-default-candidate suite?
I'm running on unstable + experimental, and installing packages from
experimental or doing upgrades with -texperimental works. What I'm doing
is picosat_set_default_phase_lit(var(ver), is_installed ? 1 : -1); - I
set the initial phase of a particular variable if picked as decision
variable.
The solver is then free to set something else if this does not work. It
will then first try the variables not marked as important, and
afterwards the ones marked as important, as far as I can tell.
>
> Don't get me wrong, I'm far from being in a position of arguing in favor
> or against any specific solver. Nonetheless I'm more than convinced that
> blessing a specific solver is risky as it's very difficult, later on, to
> get rid of the implicit requirements that the blessing poses. In looking
> for a better solver than current APT's, it is worth to make an effort to
> standardize over an interface that makes no assumptions on specific
> solving techniques. It does not necessarily need to be CUDF, but it
> should have some of its good properties, like solver technique
> independence. (i.e. AOL on Pietro's mail)
I don't see how implementing a generic solver interface using one
solution blesses a specific solver or makes assumptions on specific
solving techniques. The solver interface[1] is generic and supports
every kind of solver (such as one using clasp, one using CUDF, one using
a binary version of CUDF [let's call it BCUDF], one communicating with
external solvers using D-Bus, ...).
[1]
http://bzr.debian.org/scm/loggerhead/apt/apt/solver/annotate/head:/apt-pkg/solver.h
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: