From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22629: Channels! Date: Tue, 28 Aug 2018 23:52:21 +0200 Message-ID: <87o9dmb1m2.fsf@gnu.org> References: <87vb5vsffd.fsf@gnu.org> <87pny2iks2.fsf@gnu.org> <877ekagtg9.fsf@netris.org> 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]:59885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fulv5-00069L-Rp for bug-guix@gnu.org; Tue, 28 Aug 2018 17:53:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fulv4-0005lJ-Oo for bug-guix@gnu.org; Tue, 28 Aug 2018 17:53:03 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:59322) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fulv4-0005l3-BK for bug-guix@gnu.org; Tue, 28 Aug 2018 17:53:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fulv4-0005ch-9T for bug-guix@gnu.org; Tue, 28 Aug 2018 17:53:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <877ekagtg9.fsf@netris.org> (Mark H. Weaver's message of "Tue, 28 Aug 2018 15:52:06 -0400") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: 22629@debbugs.gnu.org Hi Mark, Mark H Weaver skribis: > I'd like to say again that I have grave concerns that this could be the > death-knell for long-term innovation in Guix. It's likely that whenever > a change is proposed that will break these third-party channels, there > will be resistance, and efforts to preserve backward compatibility. It is a risk and I acknowledge that. In the 4 years of existence of GUIX_PACKAGE_PATH, we=E2=80=99ve never encountered this issue. To what extent would that change? I don=E2=80=99t= know. I want to preserve the existing incentives to work in Guix proper, or to work closely with the project when integration in Guix proper makes little sense=E2=80=94for WIP packages, custom package variants, or domain-specific packages like those I mentioned in my message. I do not see ourselves advertising channels as the primary way to add packages. BTW, Andy=E2=80=99s Potluck offered a solution to the compatibility issue t= hat=E2=80=99s still on the table: . > I fear that with the introduction of channels, that potential will be > drastically curtailed, and that we're essentially trading our future > potential for what will in practice, most likely, be primarily used to > facilitate the use of non-free software on Guix. Non-free software will be one use case. There are other use cases though, as mentioned above; these are the ones I=E2=80=99m interested in. It=E2=80=99s a dilemma. I=E2=80=99d like to think that we can have our cak= e and eat it too; that we can give users this flexibility (which is =E2=80=9Cbuilt in=E2= =80=9D since it=E2=80=99s just a matter of setting the load path) without jeopardizing development of Guix itself, and without creating the conditions for the proliferation of non-free package channels. Whether it works this way would depend not on the technical details but on the group=E2=80=99s behavi= or. Thoughts? Thanks, Ludo=E2=80=99.