[bug#38649] [PATCH] Parallelize `guix package`

["Ludovic Courtès" <ludo@gnu.org>]

Hi Leo,

Leo Prikler <leo.prikler@student.tugraz.at> skribis:

> I think the current policy is wait-for-lock deferred to the user.  The
> user has to let the first task complete before they can start the
> second.  In this setup, the user can simply launch the setup and trust,
> that it will complete later while taking into account the changes the
> first one has made.
>
> Let's talk about three classes of operations – installations, removals
> and upgrades – and their interactions.  I will not take into account
> roll-back, switch-generation and delete-generation, as it is
> nonsensical to perform these in parallel to any other action.  Perhaps
> we could check for their presence first and acquire the lock with no-
> wait semantics in that case.
>
> - any operation on different packages: Either succeeds first and the
> other builds on the profile it generates. As there is no collision in
> the packages themselves, there will be no harm.
> - install same package twice: Either succeeds first, the other will be
> a no-op.
> - install vs. remove same package: Non-deterministic, but why would you
> do that?
> - install vs. upgrade same package: Upgrade will be a no-op in either
> case.
> - remove vs. upgrade same package: Upgrade may inadvertently upgrade
> the old package if it happens to come first, but in the final package
> it will be removed either way. 
>
> Of course, any operation can also fail midway due to some step not
> succeeding.  In that case it would be as if one had issued the other
> command right after that, which may perhaps not be what one wanted to
> do (assuming I install package A, and some guide suggests to also build
> related, but not dependency-connected package B, so I end up installing
> B without A).  However, such cases can easily be fixed by either
> installing a fixed version of A later, using B on its own if it can be,
> or rolling back.
>
> Of course, both solutions are flawed in the way that they assume user
> intent either way.  Perhaps a better one would be to let the user
> specify whether they want to wait or not through a command line
> parameter, using the current behaviour as the default approach.

I cannot think of a useful behavior if wait-for-lock were implemented.
Really, as a user, you’d be unable to know what the end result is.  I
don’t see that as very useful.  :-)

What you describe above as potential mitigation is just that,
mitigation, and it could easily become complex (as a maintainer, I
woudn’t want to be responsible for this kind of complexity :-)), and
again, for very questionable “gains”.

Thoughts?  Julien?

Thanks,
Ludo’.