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

Previous Next

Full log

Message #155 received at 22629 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Mark H Weaver <mhw <at> netris.org>
Cc: Konrad Hinsen <konrad.hinsen <at> fastmail.net>,
 Alex Sassmannshausen <alex <at> pompo.co>, 22629 <at> debbugs.gnu.org
Subject: Re: bug#22629: Channels not needed for a stable branch (was:
 Channels!)
Date: Wed, 29 Aug 2018 20:26:32 +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.

GUIX_PACKAGE_PATH already had that same problem (and did not provide a
solution for it).  With channels we can at least add more information
about a collection of modules, e.g. what version of Guix it is known to
work with.  So channels really flesh out the feature provided by
GUIX_PACKAGE_PATH, elevating it from a simple environment variable to
one that can take additional context into account.

I think that’s a worthwhile step to take.

I agree with your sentiment that a mechanism based on a simple
environment variable does not instill confidence, whereas a special
mechanism like channels could signal to users that it’s a feature that
provides some guarantees.  But I disagree with your assertion that this
would be “a death-knell to innovation”.  That seems like an exaggeration
to me.

> My point is that I want to keep our APIs internal and unfrozen for the
> same reason that Linux, the kernel project, does.  Linux refuses to
> support out-of-tree drivers and modules, and thereby retains its freedom
> to change their internal APIs.  Often they change how things work
> internally and this entails doing massive find-replace on every driver
> in the tree.  This has been a crucially important factor in their
> long-term success.
[…]
> We should persue a similar model.  The crucial thing is to always keep
> the package modules together with the rest of Guix.

I agree.  That is and remains our recommendation.  I still want most
packages to end up in Guix proper.  There are collections of packages
for which this does not make sense, though, and I think that it is
better to have a more formal mechanism that can also be used to describe
the limits of compatibility than just a simple environment variable.

I also agree with you that we don’t need channels for providing a stable
branch.  The biggest obstacle to providing a stable branch is not
technical, but it requires people maintaining it.

--
Ricardo

Previous Next

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