From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Channel dependencies Date: Sat, 20 Oct 2018 13:52:46 -0700 Message-ID: <87k1mcpcgx.fsf@gmail.com> References: <877eimnxpq.fsf@mdc-berlin.de> <87pnwbim2q.fsf@gnu.org> <87tvljknpb.fsf@mdc-berlin.de> 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]:32939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDyEz-0003Ix-U2 for guix-devel@gnu.org; Sat, 20 Oct 2018 16:52:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gDyEw-0001dd-N4 for guix-devel@gnu.org; Sat, 20 Oct 2018 16:52:57 -0400 In-Reply-To: <87tvljknpb.fsf@mdc-berlin.de> (Ricardo Wurmus's message of "Thu, 18 Oct 2018 22:24:32 +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: Ricardo Wurmus Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ricardo Wurmus writes: > [...] > >> Chris raises interesting issues. I think it=E2=80=99s OK to first come = up with >> an implementation that has some limitations but works with the simple >> use cases we have in mind. > > I=E2=80=99ve fixed this according to what we=E2=80=99ve discussed: when m= ore than one of > the user-provided or channel-required channels have the same name we > ignore the more recent specification unless it is more specific > (i.e. the new channel specification mentions a commit while the former > did not). As long as the "channel resolution mechanism" is deterministic, it's probably OK. But if you have two channels A which depends on C, and B which depends on C', where C' is a different version of C, then we can arrive in a situation where the author of A tests and provides support for their package definitions in the absence of channel B, and the author of B tests and provides support for their package definitions in the absence of channel A, and a user who wants to use packages from both A and B is stuck because one of the channel owners (the one whose dependency we didn't pick) doesn't want to support that use case. It sounds to me like we are taking all the channels are merging them into a single profile, and then we access it using a single Guix inferior. That's why we feel like we have to chose a specific version of C to use with both A and B. In this way, "installing" multiple channels into this one profile is similar to the propagation of multiple packages into a single profile. Consider package propagation. If I have a piece of software X which depends on library Z and another piece of software Y which depends on Z', where Z' is a different version of Z, then we have a similar problem. If I install packages X and Y into my profile and the libraries Z and Z' are propagated, it will cause conflicts, and we will need to choose a single version of the library. When we do that, there is no guarantee that X or Y will function correctly, since the person who developed X didn't test using Z', and the person who developed Y didn't test using Z. Instead, if we install install X and Y without propagating Z and Z', we have a solution: X and Y can coexist in the same profile. X refers to Z in the store (via its rpath or equivalent), and Y refers to Z' in another location in the store. When the user runs X, it runs using the library Z. When the user runs Y, it runs using library Z'. The user has not "voided their warranty", so to speak, by using a version of the library that the developer doesn't want to support. If there's a problem, the user can go to the developer for support more easily. I think your proposed solution is basically "channel propagation". Don't get me wrong: It's great that we can choose a specific version of channel C deterministically! This means users can share their channels.scm file and reproduce the exact channel configuration easily. However, it might be even better if we could figure out how to avoid "propagating" the channels and introducing conflicts. Maybe there is a way to run one Guix inferior per channel, so that one inferior can be responsible for packages from channel A (using C), and another inferior can be responsible for packages from channel B (using C')? By the way, even if we come up with a solution like this, I think it's safe to say that the core Guix channel must be the same version always. I can't currently see how it might make sense for two third-party channels to depend on different versions of the Guix channel, since the Guix channel provides not only package definitions but also the Guix code. I hope that makes sense. Either way, your work is already an improvement. Thank you for it! =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlvLlZ8ACgkQ3UCaFdgi Rp0Azw//ZH6CHqV8LJqtZSEFL3y59hoGL8T8xo+w91zyqdFvtZCT2yy+491MjK0P xHKtQsL5hLwPOwCyUiWrhNi52Z4p9nSW+VprRKuxs8VtZFRQ5jTpRP0byA9YOW8f Tn2mNztF8RVkXoCJE8lCDjva3KY0QTCcxswAdKjchDRhjXlbjKtk8T7tYfKN7TI4 rR2dEhpmU4dnBB3tMntopHGNbEuVPTakh/3m1it/9l0K3vxlZTeq+7+q+2oOevCI /s7kC5pgaTvuhfbQ0oWlDJLvRcBto7tnKKRWlSiMTrvLGx5V0vebqoo9x8CAOwE3 t6SwkSeR/4iQ2or4+/+3Q+H7rmGoL2/gJt4MAzOvhi3KGV4oVC7mZK6tBDAUyA8n UGX+JQG3+jbFF1ttmAkKpZREPWbKdc7NEKY47e93JMq/hu/0EhRgrsYcO3tL+gqh FzxZ9yb9Uom9y2BnwXn3K2OkHqhQcBK+znd2hZQk53/wlOXup/o+KoM8EX4KtP0j eyY2XHfg7TokpvyxqjKrYCf5svu/rUSlpQCHOguTvkMQrG2bUDW+B2VNrJQ9mclw mUAVAosGVVa+05zdkwZTqjff3/hvgEEHLqAkaGJIR75xhVnlgDYfhafe8pFzsbcq qtB+HXZTDaOQjAl5yM01QlN1R9z3sXaJ4SQUhfa3kz+o34JU7mM= =l5m9 -----END PGP SIGNATURE----- --=-=-=--