[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26608: bug#22629: “Stable” branch
From: |
Ludovic Courtès |
Subject: |
bug#26608: bug#22629: “Stable” branch |
Date: |
Tue, 04 Sep 2018 14:22:35 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hi Alex,
Alex Sassmannshausen <address@hidden> skribis:
> So the example you provided is a user-defined policy to install the
> latest version of Guix that is downloadable using substitutes (if guix
> publish has published those already).
>
> As you say, in a similar vein, the end user could for themselves define
> a policy that searches for a commit containing a specific successful
> build, or a set of specific successful builds.
Exactly.
>> 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!
>
> Your example helps visualize this, thanks.
>
> Your example depends on there being a jobset that comprises the set of
> packages you are interested in testing.
Yes, and it’s hacky in that the substitute server and jobset names are
hard-coded, but you get the idea.
> I imagine it is possible to do the same for an individual package / job.
Yes.
> The situation would be different if the end user wanted to perform a
> similar operation for an arbitrary set of packages on their end.
It would be quite similar: you would query the set of builds of an
evaluation of the “guix-modular” jobset and check whether the packages
of interest were built.
>> 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.
>
> Interesting. Do you think this kind of thing might be useful to have in
> the Guix manual? Like, in a section about a "typical" desktop end-user
> might manage their system day to day?
It would make sense to have such a section I guess. However, before
teaching users how to work around deficiencies of our infrastructure our
processes ;-), I’d like us to improve them much as possible. I’m sure
we have room for improvement for instance in Cuirass.
Thanks,
Ludo’.