bug#57315: guix upgrade --dry-run output is basically useless

[zimoun <zimon.toutoune@gmail.com>]

Hi,

Thanks for explaining.

On jeu., 01 sept. 2022 at 14:05, Ludovic Courtès <ludo@gnu.org> wrote:

>> Just to mention this report is somehow a duplicate of bug#40612 [1].
>> Maybe, they could be merged.  WDYT?
>
> Yes, please.

Done.


>> $ guix package -i opensurge --dry-run
>> guix package: warning: Your Guix installation is 12 days old.
>> guix package: warning: Consider running 'guix pull' followed by
>> 'guix package -u' to get up-to-date packages and security updates.
>>
>> The following package would be installed:
>>    opensurge 0.5.2.1
>>
>> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
>> The following derivation would be built:
>>   /gnu/store/r89hmhbxwm3gs1jl2dhns7gnwvi2k6s1-opensurge-0.5.2.1.drv
>>
>> 42.1 MB would be downloaded
>>
>> What does it mean?
>
> That you’ll download 42M of dependencies and then build opensurge.
>
> “The following derivation would be built” is about building derivations
> that are not grafts.  For grafts, you would see “The following graft …”,
> and only at verbosity level 2 or more (see ‘show-what-to-build’).

Well, the UI does not appear clear to me.


>> When I run the option ’--dry-run’, I accept to pay a bit more and then
>> compute as much as possible of derivations to have the most complete as
>> possible graph to know beforehand and as accurately as possible:
>>
>>  1. what I need to download as substitutes
>>  2. what I need to compile from source
>>  3. what require grafts, e.g.,
>>
>>         require 1 graft for openal-1.20.1 ...
>>         require 4 grafts for sfml-2.5.1 ...
>>         require 6 grafts for mars-0.7.5.1.c855d04 ...
>>
>> Sometime, the plan looks exactly like that.  Sometime, it is really
>> confusing and you have unpleasant surprises when running it.
>
> By definition, the whole plan cannot be known in advance in the presence
> of dynamic dependencies such as grafts, so it’s hard to do better.
>
> The way it’s implemented right now is not optimal strictly speaking in
> that we might bail out before we have a complete picture of everything
> that’s known statically beforehand.  In practice though I think it’s
> doing an okay job from that perspective.

Well, I understand that using the current implementation, it is not
possible to know the complete plan beforehand.  I agree that for most of
the cases, it is enough.

However, I still miss why it is not possible to compute the whole graph
of derivations.  This complete graph is potentially a bit expensive to
compute but I accept to paid this cost to have a better plan.


Cheers,
simon