GNU bug report logs - #22629
Towards a new 'guix pull'

Previous Next

Full log

View this message in rfc822 format

From: Konrad Hinsen <konrad.hinsen <at> fastmail.net>
To: Mark H Weaver <mhw <at> netris.org>, Ludovic Courtès <ludo <at> gnu.org>
Cc: 22629 <at> debbugs.gnu.org
Subject: bug#22629: Channels!
Date: Wed, 29 Aug 2018 06:09:02 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.