From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Hinsen Subject: bug#22629: Channels! Date: Wed, 29 Aug 2018 06:09:02 +0200 Message-ID: References: <87vb5vsffd.fsf@gnu.org> <87pny2iks2.fsf@gnu.org> <877ekagtg9.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:46364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1furny-0003Ll-OD for bug-guix@gnu.org; Wed, 29 Aug 2018 00:10:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1furnu-0004OJ-Ox for bug-guix@gnu.org; Wed, 29 Aug 2018 00:10:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:59478) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1furnu-0004Nm-Jj for bug-guix@gnu.org; Wed, 29 Aug 2018 00:10:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1furnu-0003gF-9y for bug-guix@gnu.org; Wed, 29 Aug 2018 00:10:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <877ekagtg9.fsf@netris.org> Content-Language: fr-classic 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 , Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 22629@debbugs.gnu.org Hi Mark, > 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 point, but the problem you mention is, in my opinion, not so much due to channels but due to different priorities of different users. Which means that it will come up even without channels as the Guix user base grows. Look at the wider Linux world: there are people who want to live on the bleeding edge and run Arch Linux, and there are others who value stability and run CentOS. Today's Guix is more on the bleeding edge side. My understanding of your commment is that you would like to make sure it stays there. But that also means severely limiting Guix' potential user base. I see channels as an opportunity to have Guix "dialects" addressing different needs and yet remain interoperable, although I am the first to admit that I have no clear idea of how this would work out in practice, more from the social than the technical point of view. But the goal looks very attractive. Looking at my own use of Guix, I am happy with its bleeding edge approach for the software I use for research, but I'd much prefer a slower pace and more stability for stuff like Emacs and TeX that are "boring infrastructure" for me. > 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. So... could we reduce the dependence of package specifications on such things? Package definitions use a small DSL that could be versioned, allowing change while maintaining compatibility. Module dependencies are more annoying, but do we need them? Package definitions are grouped into modules mostly for convenience. All packages have globally unique names, so could we use those to specify inputs? Konrad.