Re: Is there a way to upgrade only packages with substitutes?

[znavko@disroot.org]

Hello, LpRndn! Your offer places all the work at the shoulders of developers.
If we want to be more patient, we can please Ludovic Courtes to add an option --fast:

guix package -u --fast

This option will update only packages with substitutes and very small packages without substitutes (if they compile quickly). And it will not update big packages without substitutes. Realization of it we cannot assume.

This approach is related to reproducible builds. This might be not only the same result every time you compile, but the certain time it will compile.


August 3, 2019 10:19 PM, "L p R n d n" <guix@lprndn.info> wrote:

> Hello,
> 
> znavko@disroot.org writes:
> 
>> Hello, Katherine! I fuzzily remember this subject in maillists, maybe we
>> discussed this feature. And there were instruction of how to define in `guix
>> package -u` those packages you won't update.
>> Also I know guix has feature to check substitutes (`guix weather`, is it?).
>> 
>> I think we need a script that will do this:
>> 1) guix pull
>> 2) get a list of new packages and dependencies that all will be updated
>> 3) check which of them haven't substitutes
>> 4) run `guix package -u` without those packages that have not substitutes.
>> 4.1) or run `guix package -u` without only those big packages you defined like
>> 'not to update if they have no substitutes'
> 
> I also do think a way of only updating with substitutes would be nice.
> However, I'm not really fond of that behaviour. I'm pretty sure it
> has already been discussed somewhere and I probably lack knowledge to
> give a proper answer but here are my two cents.
> 
> IMHO, I would rather go for a server side solution. Something a 'simple'
> as a lagging - automated or curated - channel could do the trick. (1
> day, 1 week with/out meaningfull commits)
> Obviously, that means, a minimal profile won't be able to get its
> substitutes as soon as possible but the difference shouldn't be that
> large anyway (what is it? 24h? 48h?). Plus, it's a gain in term of computation,
> speed of update, use of network etc.
> 
> Also, any tool that would automatically resolve in a potential partially
> updated profile, even if advertised, is probably a door to a lot of
> incomprehension and unwanted behaviour. --do-not-upgrade and -u $package
> are ok because the user take an active part in it.
> 
>> I think this can be done with guix features but this is hard work, not for usual users.
>> And sure guix must have this feature.
>> 
>> August 2, 2019 8:42 PM, "Katherine Cox-Buday" <cox.katherine.e@gmail.com> wrote:
>> 
>>> Hey Guix!
>>> 
>>> Very often I find myself updating systems only to get stuck on building
>>> something large like LibreOffice or Un-Googled Chromium. Usually the
>>> substitutes for these are available a few days later.
>>> 
>>> It would be nice if I could pass a flag to `guix package -u` that would
>>> disallow building in the event a substitute wasn't available. Is that
>>> `--fallback=false`? If so, that's a double-negative; is there a clearer
>>> way to represent both without acreting options?
>>> 
>>> --
>>> Katherine
> 
> Have a nice day,
> 
> Lprndn