From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Sassmannshausen Subject: bug#22629: Channels! Date: Wed, 29 Aug 2018 11:29:50 +0200 Message-ID: <87zhx5msfl.fsf@pompo.co> References: <87vb5vsffd.fsf@gnu.org> <87pny2iks2.fsf@gnu.org> <877ekagtg9.fsf@netris.org> Reply-To: alex@pompo.co 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]:33538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuwng-0003Xk-JZ for bug-guix@gnu.org; Wed, 29 Aug 2018 05:30:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fuwnb-0006a3-IL for bug-guix@gnu.org; Wed, 29 Aug 2018 05:30:08 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:59613) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fuwnb-0006ZT-7U for bug-guix@gnu.org; Wed, 29 Aug 2018 05:30:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fuwnb-0003Pl-0J for bug-guix@gnu.org; Wed, 29 Aug 2018 05:30:03 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <877ekagtg9.fsf@netris.org> 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 Mark H Weaver writes: > Hi Ludovic, > > ludo@gnu.org (Ludovic Court=C3=A8s) writes: >> Currently third-party channels are expected to provide nothing but >> package modules. > > 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. I understand your concerns and want to acknowledge those. My primary interest in channels at the moment comes from believing that having a "stable" channel would be incredibly useful to increase adoption rate of Guix. And for me. Currently upgrading my system involves doing a guix pull, then, over the course of a few days, doing guix package -u and bailing out if I start building a large program. After this I do guix system build, and bail out if a large program starts building. In either case, if an upgrade broke a dependency then I'm kind of stuck at the old versions of my profile. Finally, when I've upgrade profile and system, I immediately run guix pull to prepare for the next cycle. I consider myself pretty capable, and I find this process stressful =E2=80= =94 I certainly cannot envisage most of my currently interested friends going through this process=E2=80=A6 But like I say, this is not to discount your concerns, it is merely to add to the list of reasons why channels might be important. Best wishes, Alex > Even things as seemingly innocuous as moving a package from one module > to another will impact these third-party channels, not to mention > changing our internal APIs or making fundamental changes to the way > packages are specified. > > Part of why I'm so interested in Guix is because it currently has nearly > unconstrained potential to grow into something far more beautiful and > elegant than it is today. > > 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. > > When I start to see signs of resistance to changes for the sake of > third-party channels, then I'll know I was right to be fearful, and > Guix will become far less interesting to me. > > Mark