I'd like to be able to select a specific channel to be updated when running a
"guix pull" command.
Let's say I have a "channels.scm" file, containing 3 channels: "abc", "xyz" and
"guix", all pointing to the branch "main". When running "guix pull", all three
channels get updated via a "git pull",
Shall we close this bug?
Having a checksum would at least be more declarative and self-contained, but
not as convenient. A variation of this idea is to not have the checksum, and
allow the tarball to be changing over time, like a tarball representing a branch
on a repository that gets commits over time.
This is a reasonable compromise. It is less self-contained than a single
channel file definition, and requires me or the consumer a bit more upfront
setup, but I'm OK with that.
I'm very much in favor of keeping the current channel implementation leveraging
aspects specific to Git, and I also don't think that adding any other DVCS is
worth it.
In this model, downgrade prevention would a) be inexistant or b) require work
from the upstream tarball provider, to produce tarballs with metadata files that
could provide such data.
Authentication could be done by relying on TLS, or requiring a signature file.
I agree with most points, but I'm not proposing creating integrations with other
DVCS, en par with the current Git integration.
My proposal was a little more crude: get the channel code from a tarball. In
this model there are no authentications with fingerprint or signed commits,
neither "guix pu
As I've described in [0], one can't have a Guix channel served over Git's
"Dumb HTTP" protocol. That is caused by libgit's inability to do so [1].
Guix channel authors may want to serve channels:
- via "Dumb HTTP" Git repositories;
- via other DVCS like Mercurial, Fossil, BitKeeper;
- decoupled f
Hello :)
Jumping in the discussion xD
Ludovic Courtès writes:
> Yes, I think it is clear that we’d have to do this using all the tools
> at our disposal, including time.
>
> Konrad’s objection remains though: existing documents (papers, blog
> posts, MOOCs, etc.) that mention ‘guix environment’
