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

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



(picking up were I left nearly a month ago… sorry again)

On Wed, Dec 18, 2013 at 10:38:44PM +0100, Stefano Zacchiroli wrote:
> 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

It's based on "AllVersions should be false" as it's makes the most sense
nowadays, but can't be as scripts depend on it… *sign*
aptitude has fixed that. The more graphical frontends also just show
information for the candidate. If we go abstract, the news/release
notes/reviews will talk about that one as well.

(Its frustrating enough that the version from the default release
 sometimes doesn't include the feature I was expecting it to have,
 but at least I get the version everyone else got, not the one from
 oldstable because the unstable one isn't installable at the moment)


> not specifying one probably means "I don't care which version, just give
> me one" (= the candidate).

This doesn't make sense to me. "just give me one" means for me
absolute freedom: oldstable, experimental, or anything in between.
"(= the candidate)" is the opposite.

I realise that a lot of times any version of "foo" will do, so
"apt-get install foo" could very well install any version in that case,
but there are also quiet a few moments in which I do the exact same
request, but actually mean "foo (>= implementing feature X)", but don't
know about that version requirement as I have just read in the
description/review/heard from a friend that it does X.


> > 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?

No and yes.

I believe that it is the job of the front end to figure out which
versions of 'foo' are okay with the user – as 'foo' is what the user
will use and interact with.

All bets are off¹ for what foo has as dependencies though, as the user
isn't interacting with those directly (in an ideal world²) – it is the
problem of 'foo' to work with them and as it is way better at expressing
what it needs aka: dependency resolvers workplace.

¹ depending on strict pinning setting
² probably fails tragically with meta/task-packages, but so be it (for now)


> 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.

Indeed, neither the resolver language nor the front ends are capable of
allowing the user to express that at the moment, but as said I doubt
this should be all burdened on the shoulders of the dependency
resolvers, especially as I could imagine that users might use very
different policies for both (like more "stable" for dependencies and
more "cutting-edge" for everything used directly).


> 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.

I hope its clear now that this is based on a misunderstanding. I am fine
with flexibility if it is limited to dependencies in its current form.
I would be even fine with flexibility in the dependers version itself,
but if that flexibility is available isn't in the resolvers mercy and
that is what this give-commandline-to-resolver seems to enable.


> > 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.

[… another misunderstanding. I should work on making myself more clear …]

> 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.

Sure. APT-Candidate doc says "When set to `yes`, the corresponding
package is the APT candidate for installation among all available
packages with the same name." which isn't true in Multi-Arch world
as libfoo:i386 and libfoo:amd64 can have different candidates
(usually with undesired consequences), but have the same name.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature


Reply to: