From: Jelle Licht <jlicht@fsfe.org>
To: Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: [RFC] A simple draft for channels
Date: Fri, 19 Jan 2018 09:55:45 +0100 [thread overview]
Message-ID: <CAPsKtf+=sFnqUtBfQ3oiH-qBQyEB-7BdZvaZXE6J=YN9Yfo16Q@mail.gmail.com> (raw)
In-Reply-To: <87bmhq6ytg.fsf@mdc-berlin.de>
[-- Attachment #1: Type: text/plain, Size: 3439 bytes --]
2018-01-19 9:24 GMT+01:00 Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>:
> Hi Guix,
>
> I’d like to retire GUIX_PACKAGE_PATH as the main way to get third-party
> packages, because we can’t really keep track of packages that were added
> or redefined in this way. I want to replace it with slightly more
> formal “channels”.
>
> As a first implementation of channels I’d just like to have a channel
> description file that records at least the following things:
>
> * the channel name (all lower case, no spaces)
> * a URL from where package definitions can be loaded (initially, this
> can be restricted to git repositories)
>
> Optional fields:
>
> * a description of the channel
>
> * a URL from where substitutes for the packages can be obtained (this
> will be backed by “guix publish”)
>
> * a mail address or URL to contact the maintainers of the channel, or to
> view the status of the channel
>
> * the Guix git commit that was used when this channel was last
> updated. This is useful when Guix upstream breaks the ABI or moves
> packages between modules.
>
> On the Guix side we’d need to add the “guix channel” command, which
> allows for adding, removing, updating, and downgrading channels. Adding
> a channel means fetching the channel description from a URL and storing
> state in ~/.config/guix/channels/, and fetching the git repo it
> specifies (just like what guix pull does: it’s a git frontend). It also
> authorizes the the substitute server’s public key.
>
> Internally, it’s just like GUIX_PACKAGE_PATH in that the repos are used
> to extend the modules that Guix uses. Unlike GUIX_PACKAGE_PATH,
> however, we now have a way to record the complete state of Guix,
> including any extensions: the version of Guix and all active channels
> with their versions. We would also have a way to fetch substitutes from
> channels without having to “globally” enable new substitute servers and
authorize their keys.
[...]
> (Is this safe? Can we have per-user extensions
> to the set of public keys that are accepted?)
>
> I am not sure, but I think we need to be able to ensure that these 'new'
substitute servers
will only be used to get substitutes for the derivations in that specific
channel.
I am not sure how easy it will be to make sure this will be the case, but I
guess we do not
want to give any user-defined the possibility to 'overwrite' substitutes
for existing derivations
from system-trusted substitute servers.
Downsides: Guix has no stable ABI, so channels that are not up-to-date
> will break with newer versions of Guix. Moving around packages to
> different modules might break channels. That’s okay. It’s still an
> improvement over plain GUIX_PACKAGE_PATH.
>
> We might be able to mitigate this by using by using Semantic Versioning [1]
on a best-effort basis. Perhaps (some) changes to the abi could even be
picked up and warned
about by a tool not unlike the one used to generate the package listings
for new releases. I am
thinking of things like:
- A package was renamed (so the previous named version no longer exists)
- A package was moved
> I don’t think it has to be more complicated than that. What do you
> think?
>
> --
> Ricardo
>
> In general, I like it and would love to play around with this soon.
- Jelle
[1]: https://semver.org/
[-- Attachment #2: Type: text/html, Size: 4708 bytes --]
next prev parent reply other threads:[~2018-01-19 8:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-19 8:24 [RFC] A simple draft for channels Ricardo Wurmus
2018-01-19 8:55 ` Jelle Licht [this message]
2018-01-19 11:30 ` Pjotr Prins
2018-01-19 13:41 ` Ludovic Courtès
2018-01-19 13:56 ` Pjotr Prins
2018-01-23 6:38 ` Ricardo Wurmus
2018-01-23 8:54 ` Pjotr Prins
2018-01-23 23:01 ` Carlo Zancanaro
2018-01-23 16:03 ` myglc2
2018-01-23 16:50 ` ng0
2018-01-24 5:44 ` myglc2
2018-01-24 12:33 ` ng0
2018-01-24 15:04 ` Konrad Hinsen
2018-01-23 20:39 ` Ricardo Wurmus
2018-01-23 20:37 ` Ricardo Wurmus
2018-01-24 12:01 ` Pjotr Prins
2018-01-20 5:45 ` 宋文武
2018-01-24 14:08 ` Ludovic Courtès
2018-01-24 17:55 ` myglc2
2018-01-24 18:20 ` Ricardo Wurmus
2018-01-26 17:23 ` myglc2
2018-01-26 18:53 ` Oleg Pykhalov
2018-03-19 12:46 ` ng0
2018-01-27 12:10 ` Chris Marusich
2018-03-19 12:04 ` [Orchestration][RFC] " Pjotr Prins
2018-03-19 12:36 ` ng0
2018-03-19 18:21 ` myglc2
2018-03-19 18:31 ` Pjotr Prins
2018-03-19 20:18 ` myglc2
2018-03-19 20:29 ` Pjotr Prins
2018-03-20 7:02 ` Pjotr Prins
2018-03-20 10:41 ` Ricardo Wurmus
2018-03-20 13:10 ` Pjotr Prins
2018-03-20 13:41 ` Ricardo Wurmus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPsKtf+=sFnqUtBfQ3oiH-qBQyEB-7BdZvaZXE6J=YN9Yfo16Q@mail.gmail.com' \
--to=jlicht@fsfe.org \
--cc=guix-devel@gnu.org \
--cc=ricardo.wurmus@mdc-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.