From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:58806) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihaSh-00039Y-J6 for guix-patches@gnu.org; Wed, 18 Dec 2019 09:38:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihaSg-0000rX-91 for guix-patches@gnu.org; Wed, 18 Dec 2019 09:38:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:36830) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ihaSg-0000pW-4G for guix-patches@gnu.org; Wed, 18 Dec 2019 09:38:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ihaSf-0002t3-U0 for guix-patches@gnu.org; Wed, 18 Dec 2019 09:38:01 -0500 Subject: [bug#38649] [PATCH] Parallelize `guix package` Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87tv5zrpjp.fsf@gnu.org> <3d0ca2a8b59dd99e15b55033bc89b2e21aa49814.camel@student.tugraz.at> Date: Wed, 18 Dec 2019 15:37:45 +0100 In-Reply-To: <3d0ca2a8b59dd99e15b55033bc89b2e21aa49814.camel@student.tugraz.at> (Leo Prikler's message of "Tue, 17 Dec 2019 16:19:34 +0100") Message-ID: <87lfr9pume.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Leo Prikler Cc: julien lepiller , 38649@debbugs.gnu.org Hi Leo, Leo Prikler 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 =E2=80=93 installations, rem= ovals > and upgrades =E2=80=93 and their interactions. I will not take into acco= unt > 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.=20 > > 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=E2=80=99d be unable to know what the end result is. = I don=E2=80=99t 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=E2=80=99t want to be responsible for this kind of complexity :-)), and again, for very questionable =E2=80=9Cgains=E2=80=9D. Thoughts? Julien? Thanks, Ludo=E2=80=99.