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

[Julien Lepiller <julien@lepiller.eu>]

Le 17 décembre 2019 16:19:34 GMT+01:00, Leo Prikler <leo.prikler@student.tugraz.at> a écrit :
>
>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.
>
>WDYT?

I might be missing something. Guix install etc act on a "hidden" descripcion of the profile. Tgey take the current profile, modify it as specified (adding a package, renovinh another or upgrading some). When you run two guix package in parallel, they both work on the same profile, which creates unexpected results.

The expectation behind tge lock is that users will cancel tge ocher command and fix it before re-running it (e.g. instead of guix install foo & guix install bar, run guix install foo bar).

>
>Regards,
>Leo