bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22629: Channels!


From: Konrad Hinsen
Subject: bug#22629: Channels!
Date: Wed, 29 Aug 2018 06:09:02 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]