From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Channel dependencies Date: Tue, 23 Oct 2018 00:44:27 -0700 Message-ID: <87va5t2jl0.fsf@gmail.com> References: <877eimnxpq.fsf@mdc-berlin.de> <87pnwbim2q.fsf@gnu.org> <87tvljknpb.fsf@mdc-berlin.de> <87k1mcpcgx.fsf@gmail.com> <87va5umbm1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gErMl-0003xN-WB for guix-devel@gnu.org; Tue, 23 Oct 2018 03:44:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gErMi-0004bJ-R8 for guix-devel@gnu.org; Tue, 23 Oct 2018 03:44:39 -0400 In-Reply-To: <87va5umbm1.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 22 Oct 2018 14:04:06 +0200") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org, Ricardo Wurmus --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Good point. I agree that it=E2=80=99s similar to the question of propaga= ted > 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. In other words, both packages provide "the same" file. With channels, we build a profile containing the union of the channels. So, normal profile conflicts will definitely occur in the profile if two channels provide the same module (e.g., $out/my/awesome/packages.scm), right? Because we're putting the two channels into a single profile, I think the normal conflict resolution mechanism will force us to use only one module in the resulting profile. And I think that if two channels provide the same module, it's definitely a conflict of some kind. Furthermore, if two channels both provide "the same" package definition for a tool called my-awesome-program in two different modules, Guile scheme code can still specify precisely which my-awesome-program should be used. In that sense, there is no conflict. However, if both package definition use the same name and version, then a command like "guix package -i my-awesome-program" (and the APIs that convert package specifications to packages) will have to choose one specific package, right? In that sense, there is a conflict. It seems to me that these kinds of conflicts are what we want to avoid. Regardless of what the channel is named, regardless of what URI it comes from, regardless of what commit it came from, if it provides the same modules or the same packages as another channel, there's a "channel conflict". However, detecting that sort of conflict seems pretty complicated. I don't have a good idea for how to detect it. It seems like you would have to traverse the entire set of modules and packages that a channel provides, and cross-check it with other channels to make sure there are no conflicts. We might have to use multiple inferiors to do that, like you mentioned. 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. > 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 a= ny channel with the same name > but a different =E2=80=98uri=E2=80=99 and/or a different =E2=80=98bra= nch=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, th= en 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. > 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! =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlvO0VsACgkQ3UCaFdgi Rp1aCxAAg+BaWIccvtx6qSAguBwRevoB5U/hiOVvRgYgY4uBGZqHX4jNCRa7inNB uS7LbD0xEtWS/8SRjDolsU8sIfTu23DIV14RG8LidXbpV8SfdOYQpKeYI3s0X8IM 0zTWyez3F4eMEvICG6kmWJxDkbSa/dpXaYj2XQI/lSMDdOwiOcEV6KohbQj3iBGt MfSjgNDxsfPteta0rPo6hTSb/f+fVvggPo3KmDemDEAe1Xz6eaF9q46ho77gUcPQ E8jConWFyRKl5PvHDNb1m+ZVgbbiNx85XEsXglPRP4KtlPiBeQuRxB5AB1ZvC1OJ tTrsLdcsE8z0apf9j6QGqE3FdWlm8v+/RMiyt7sW7PI3exIeqOqXQezR/if2Zerm GtjDFLb53otOUf7mAHudMDVQ0aKMF7iQkoF/bZi9uhwMJlwqZA9foiiFVLTQqBmi F4rIJZuhrh0l92/3dYVJDbQy1R6ZAX7OXO64MOOFcZ/IJH3Sgvt68cd7v2Dnwr1o /yHLoKWA1gX28xHxldOpi/BuNoGnBzZaMc8ybCd5HWmogpwGLx8cTVX9PcUpeEQJ UXnCRoo3z/jt8P+oFvkPejDZrMHGAWqTaylN13mzLzG3BhN6n/gX8QShiAork+CQ skLLxbb8rpMtP+Oo56noq4Q29Rd5GXeSFaMdz2+GlLZXrN/VjXk= =fqlF -----END PGP SIGNATURE----- --=-=-=--