From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Channel dependencies Date: Wed, 24 Oct 2018 15:14:11 +0200 Message-ID: <87tvlb32sc.fsf@gnu.org> References: <877eimnxpq.fsf@mdc-berlin.de> <87pnwbim2q.fsf@gnu.org> <87tvljknpb.fsf@mdc-berlin.de> <87k1mcpcgx.fsf@gmail.com> <87va5umbm1.fsf@gnu.org> <87va5t2jl0.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFJ41-0000YX-M7 for guix-devel@gnu.org; Wed, 24 Oct 2018 09:19:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFIzF-0007XP-Fm for guix-devel@gnu.org; Wed, 24 Oct 2018 09:14:18 -0400 In-Reply-To: <87va5t2jl0.fsf@gmail.com> (Chris Marusich's message of "Tue, 23 Oct 2018 00:44:27 -0700") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org, Ricardo Wurmus Hello! Chris Marusich skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Good point. I agree that it=E2=80=99s similar to the question of propag= ated >> inputs, which we deal with by reporting an error when a collision >> arises. >> >> So, similarly, I think the safe way would be to report an error when >> channel requirements conflict. > > With profiles, two packages conflict if and only if a file exists at the > same relative path in both packages' outputs. What you describe here are =E2=80=9Csoft collisions=E2=80=9D, which the pro= file builder reports as warnings (which are invisible with today=E2=80=99s =E2=80=98guix= package=E2=80=99.) I was referring to profile collisions where two packages with the same name end up in the same profile (the =E2=80=98&profile-collision-error=E2= =80=99 exception.) This exception would also be raised if =E2=80=98guix pull=E2=80=99 ended up= adding the same channels more than once in ~/.config/guix/current. > Also like you said, we can try to implement some heuristics to reject > situations in which a "channel conflict" is likely. Would it be hard to > change the channel mechanism so that it fails if there are any (normal) > conflicts while generating the profile that contains all the channels? > If we could prevent those (normal) conflicts while generating the > profile, it would prevent a certain class of channel conflicts: namely, > it would be impossible for two channels to provide the same guile > modules. =E2=80=98union-build=E2=80=99 has a #:resolve-collision parameter. We coul= d set it when building ~/.config/guix/current so that an error is raised when the same file is provided more than once. (It=E2=80=99s a simple change we can make independently of what Ricardo is proposing.) WDYT? >> We must define what it means for two s to conflict: >> >> =E2=80=A2 if a channel=E2=80=99s =E2=80=98commit=E2=80=99 is #f, then = any channel with the same name >> but a different =E2=80=98uri=E2=80=99 and/or a different =E2=80=98br= anch=E2=80=99 and/or a non-#f >> commit conflicts; >> >> =E2=80=A2 if a channel=E2=80=99s =E2=80=98commit=E2=80=99 is not #f, t= hen any channel with the same >> name and otherwise different fields conflicts. > > This seems like a reasonable heuristic. What will we do when two > channels differ only in their name? What about when two channels only > have identical fields? Maybe in those cases we should just pick one, > ignore the other, and log a warning, since their content will be the > same. Yes, they would effectively be =E2=80=98equal?=E2=80=99. >> If we have inspiration later, we can liberalize this, for instance by >> using several inferiors. It would be quite a bit of extra work, and >> it=E2=80=99s not immediately clear to me how that could work. I believe= what >> Ricardo proposes already covers many use cases anyway. > > You're probably right. I'm just trying to think about how we might > apply the functional model to this problem, rather than implementing > heuristics. But maybe heuristics are good enough! Sure, and that=E2=80=99s good! Thanks, Ludo=E2=80=99.