Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build)

[Björn Höfling]

On Tue, 26 Feb 2019 23:29:35 -0800
Chris Marusich <address@hidden> wrote:

> Hi Giovanni,
> 
> Giovanni Biscuolo <address@hidden> writes:

[...]

> >   anyway even if that is not the issue, users should have some way
> > to check if a substitute is available for their current commit, so
> > they can decide if they are willing to locally build or not.
> >     
> >   also, it would be useful if "guix package -i/-u" allowed users to
> >   choose to fail (via a flag or a CLI prompt) in case a substitute
> > is not available; AFAIU "Substitution failure" [1] works when a
> >   substitute *is available* but download fails (and we have
> > "--fallback" just in case), but there is non way to fail in case
> > substitute in not available.

There is already a bug created about this topic: "do not attempt to
build a package known to be broken":

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33737

It seams like the discussion faded out because the daemon is not yet
ready for this, and there were some discussions about corner cases like
indeterministic build failures.

> >   in my specific case with ungoogled-chromium, it took about 8
> > hours on a 8 cores + 16GB RAM machine (although heavily used) to
> > reach 75% of the build process... and finally I had to cancel the
> > build since the machine load reached 40 (since other "heavy"
> > processes started via cronjobs).)  

Another related topic discussed before (I'm not sure if there is a
ticket for this) is to collect build resource consumption (wall-time,
cpu-time, memory-usage, ...) and store it in a local or even
global database. With that data available you could at least roughly
calculate the cost of compilation and if you want to put that effort in
(or to plan your heavy compilation say overnight).

> I agree it would be nice if one could control the behavior more
> easily. However, someone needs to put in the time to design and
> implement the solution.  So far, I think people with time and energy
> have chosen instead to focus on improving substitute availability, in
> the hopes that it will prove more useful in the long term.
> 
> Would you be interesting in working on it?  I have sometimes wanted a
> feature like that, but I do believe substitute availability will help
> more in the long term.

I found with a huge profile there is always some dependency failing.
And it is not clear which leaf packages to exclude to "just" update the
rest of your profile. This could be automated. I would like to see that
feature.

Though on the other hand as you said, everyone's resources are limited
and we tend to look at the packages and getting them fixed.

Björn

pgpc1WnU0FsB2.pgp
Description: OpenPGP digital signature