[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22629: “Stable” branch
From: |
Ludovic Courtès |
Subject: |
bug#22629: “Stable” branch |
Date: |
Mon, 03 Sep 2018 21:52:00 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hi Alex,
Alex Sassmannshausen <address@hidden> skribis:
> Ludovic Courtès writes:
[...]
>> I just had a bright idea (yes!): this can be addressed by writing
>> something like this in ~/.config/guix/channels.scm:
>>
>> (map latest-commit-with-substitutes-available
>> %default-channels)
>>
>> The hypothetical ‘latest-commit-with-substitutes-available’ would use
>> (git) and (guix ci) to find the latest commit for which substitutes of
>> interest are available, and would return:
>>
>> (channel
>> ;; …
>> (commit "cabbag3")) ;the ideal commit
>
> This sounds incredibly interesting — and it is testament once again to
> the power of Guix that this kind of solution could be feasible!
Just to be clear: I don’t think this would be a substitute for a
“stable” branch; rather, I view as a way to have user-defined policies
such as “pull up to the latest commit for which there’s a substitute for
IceCat.”
> Thinking this through in my head somewhat, I had the following thoughts:
> - This procedure is invoked client side, where the channel is defined
> - That means the git searching is done client side, on every invocation
> of guix (I guess this might be cacheable?)
On every invocation of ‘guix pull’ only.
> I have no idea what the performance cost would be. I guess you would
> use "guix weather" to turn the set of requested packages into a manifest
> which can then be checked with it.
As I imagine it, the cost would be a few HTTP queries to the Cuirass
API. I should try to come up with an example to better explain what I
had in mind!
> The question of security updates is tricky at the moment already — I
> would hazard a guess that many people bail out of upgrading when they
> can't get substitutes for their entire profile / system right now, which
> means they are not getting security upgrades for package (a) when a
> substitute for (b) fails.
That’s probably true, and I agree it’s problematic.
What I typically do is “guix pull && guix package -n -u”. Then I look
at things that would be built; if, say, LibreOffice is among them, I
wait for a little while and try again later, until I can get enough
substitutes. That usually works okay, but it fails if it turns out that
one of the dependencies fails to build: substitutes never become
available in that case.
Ludo’.