On Tue, 26 Feb 2019 23:29:35 -0800 Chris Marusich <[email protected]> wrote:
> Hi Giovanni, > > Giovanni Biscuolo <[email protected]> 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
pgpCtWB85fv5F.pgp
Description: OpenPGP digital signature
