On 2017-03-21 00:11:19 +0100, Manuel A. Fernandez Montecelo wrote:
> 2017-03-07 3:48 GMT+01:00 Vincent Lefevre <vinc...@vinc17.net>:
> > On 2017-03-06 22:57:18 +0100, Manuel A. Fernandez Montecelo wrote:
> >> 2016-09-05 02:33 Vincent Lefevre:
> >> > On 2016-09-05 01:50:04 +0200, Vincent Lefevre wrote:
> >> > > In the UI, I've selected various packages for upgrade; I can see
> >> > > no breakages. But the 'g' key doesn't have any effect, it just
> >> > > says: "[1(1)/...] Actions: no changes" with no explanations.
> >> >
> >> > And 'e' (Examine) just says:
> >> >
> >> > --\ Leave the following recommendations unresolved:
> >> > libmtp9 recommends libmtp-runtime
> >> >
> >> > libmtp9 recommends libmtp-runtime
> >> > --\ The following actions will resolve this dependency:
> >> > -> Cancel the removal of libmtp-runtime
> >> > -> Downgrade libmtp-runtime [1.1.12-1 (now, testing, unstable) ->
> >> > 1.1.8-1+b1 (
> >> > -> Leave the dependency "libmtp9 recommends libmtp-runtime" unresolved.
> >> >
> >> > which makes no sense since nothing related to libmtp is proposed.
> >>
> >> This was implemented after your complaint in #819636 (not upgrading
> >> "lightly" if it means breaking a recommend relationship), which then
> >> needed #822329 to not be so eager on fixing unfulfilled recommends.
> >
> > Except that libmtp-runtime was already installed, so that the
> > dependency was satisfied! And I didn't request it to be removed.
> > So, the above message is simply buggy.
>
> libmtp9 recommends libmtp-runtime (no version), but libmtp-runtime
> depends on libmtp9 (= ${binary:Version}), so they have to be upgraded
> in lockstep (and now sure what part the binnmu version would play here
> if libmpt-runtime was arch:all). Maybe the broken recommendation is
> related with them having to be in the same exact version.
The proposed action "Downgrade libmtp-runtime [1.1.12-1 (now, testing,
unstable) -> 1.1.8-1+b1" would have broken the dependency.
Why wasn't the following action proposed?
Keep the ... packages at their current version.
> > In any case, "Actions: no changes" is not a meaningful error message and
> > isn't even documented anywhere (neither in the man page, nor in the manual).
> > So, the fact that this message appears is a bug.
>
> I don't agree that "actions: no changes" is a meaningful error
> message, because that is not even an error message.
>
> It's the proposed solution to solve an inconsistency in the (future)
> state of a system. In this context, "no changes" means to not
> install, remove, upgrade etc. any package, and it's a perfectly valid
> recommendation of the resolver to solve the inconsistency.
It is not clear that this is a decision from the resolver. I thought
it meant that the user requested no changes.
Something like the following would be clearer:
The resolver decides: no changes.
Well, the resolver should be mentioned in the message.
Or perhaps better than "no changes":
...: keep all packages at their current version.
("no changes" is too vague, IMHO).
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
