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

Previous Next

Package: guix;

Reported by: ludo <at> gnu.org (Ludovic Courtès)

Date: Thu, 11 Feb 2016 10:36:02 UTC

Severity: important

Merged with 28471

Done: ludo <at> gnu.org (Ludovic Courtès)

Bug is archived. No further changes may be made.

Full log


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

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

Konrad Hinsen <konrad.hinsen <at> fastmail.net> skribis:

>> Mark’s concern is not about whether packages are the latest version,
>> etc.  It’s about the constraints that could result from widespread
>> development of channels outside Guix proper: technically all of Guix is
>
> That's how I understood it as well. If/when Guix becomes somebody else's
> dependency, then there will be pressure on stability in Guix itself.
>
> My point is that this will happen anyway if Guix is adopted more widely.
> Every manifest file, personal or shared as part of a software package
> ("guix.scm"), relies on the same technical details as a
> channel. Introducing channels only makes the issue more visible.

True.  Manifests can rely on fewer details of the API than a channel
though, particularly if they use ‘specifications->manifests’.

(BTW code in channels could use ‘specification->package’ as well to
increase decoupling a bit.)

> And this is really the same issue as with the stability of the packages
> themselves, Guix being a kind of superpackage. Most people want agility
> for the software layer they are most concerned with, and stability for
> all layers below it. For Mark (and certainly others here), Guix happens
> to be the layer they are most concerned with.

Yeah.

Thanks,
Ludo’.




This bug report was last modified 6 years and 322 days ago.

Previous Next


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