GNU bug report logs -
#22629
Towards a new 'guix pull'
Previous Next
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):
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.