Re: [patch] EDSP 0.5 w/ multi-arch support for external solvers

[Stefano Zacchiroli <zack@debian.org>]

Heya, sorry for the delay, [insert here "end of semester" or similarly
lame excuses].

On Wed, Nov 27, 2013 at 01:18:54PM +0100, David Kalnischkies wrote:
> Okay, lets just recap so that we are on the same page:
> My start point is that I want to understand why you want to promote the
> commandline to be an official part of the protocol, which I consider an
> enormous hack while you say you need it for users.

Fair enough. FWIW, it's not like I want all of the command line to be
part of the protocol, I'd be more than satisfied with an abstract "user
request" object. Passing the command line is a way to achieve that,
arguably an overabundant one.

> Which packages are mentioned on the commandline is already transported,
> so it can only be that you want to know which versions are explicitly
> vs. implicitly requested for those packages.

Correct.

> My stanza is basically that there is no difference as no version means
> candidate as all information is displayed for candidate.

What is the scope of your "all information" statement here? Is it
apt-get alone, or the apt-* suite at large? I ask because, for instance,
APT::Cache::AllVersions defaults to true for "apt-cache show", meaning
that the user is exposed to multiple package versions when inquiring
about a package (I routinely sets it to false because I find it
annoying, but that's an unrelated matter :-)). For that reason, in a
usage session where the user has just run of apt-cache show, I find it
entirely normal for the user to specify an explicit version to apt-get,
in order to the versions she wants among those she has just seen. OTOH
not specifying one probably means "I don't care which version, just give
me one" (= the candidate).

> So it is either the task of the solver(-wrapper) to remove the
> not-requested versions from the scenario or it's the task of the
> frontend to not include them in the scenario.
> 
> I assumed that the first one is currently the case (even if the second
> is probably better), regardless of what StrictPinning defines with all
> the reasons/examples I mentioned before as I believe that otherwise it
> is very hard to use in practice.

It's here that I don't follow your reasoning. It seems to me that you're
saying that the solver should never consider non-candidate versions,
neither for packages explicitly mentioned by the user, nor for their
dependencies. And you're pondering whether the pruning needed to
implement that should be done by the solver or by the frontend. Am I
reading you right?

If so, my first comment is that this will be a deviation (in worse) from
what we can currently do. In particular, Strict-Pinning=yes would become
entirely useless.

The second comment is that I don't get why you want to make it
impossible for the solver to have potentially useful information, rather
than documenting what is the expected result. A user using testing might
want to express fancy criteria such as "install this package (in its
candidate version) but please check that its version is the same in
stable", dunno to ease backports, portability of compiled binaries,
whatever. It's not like the current preference language for solvers in
apt-cudf allows to do that, but with your proposal here the solver has
not only no way to "be flexible" (as in: StrictPinning=false) but also
no way to implement any criteria that relate together packages coming
from different suites.

Regarding "being flexible", it's clear to me that while for me it's a
feature, for you is not. But either we're gonna pull it, or we rely on
safeguards. Other than making it opt-in, and forcing users to explicitly
request it using a not-that-easy-to-find-option, I don't know what other
safeguards I could add. Honestly, I really don't understand what is so
terrible about it, it's not like it's worse than Force-yes or
Force-Downgrade.

This is my current understanding of your concerns. But if I've missed
something I'm all ears!

> Beside that, the flat-archive/no-release thingy I mentioned is
> blocking

This one should now be fixed as per my other post of today,
https://lists.debian.org/deity/2013/12/msg00041.html

> and the documentation should be check for sentences suggesting that
> the package name alone is an identifier. The doc for APT-Candidate
> e.g.  sounds a bit like it.

By the look of it, the current documentation use "package" to actually
mean "versioned package". Here is for instance the initial description
of the package universe:

  #### Package universe

  A package universe is a list of Deb 822 stanzas, one per package,
  called **package stanzas**. Each package stanzas starts with a Package
  field. The following fields are supported in package stanzas:

consistently, the doc seems to be using "package name" to mean something
like "all packages with the same name but (potentially) different
versions". We can replace "package" for "package version" everywhere,
but I fear it will make the text more cumbersome, for no clear advantage
(at least not to me). I'm not against doing that, but I'd rather be sure
to get what you mean before potentially making the test worse.

Maybe you can show me how would you change the documentation for
APT-Candidate? Once I get what you mean here, I'll be happy to reread
the protocol documentation and propagate the change wherever is needed.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »