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

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

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

[Forget to reply to OP, resending ...]

Hello Katherine,

Katherine Cox-Buday writes:

> 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?

I don't think there is an option for this. It would certainly be helpful
if there were one.

Currently, my workaround is to create a manifest listing packages to be
installed:
https://notabug.org/alexvong1995/guix-package-declaration/src/master/manifest
and run "guix package -m ./manifest" instead of "guix package -u".

[emacs-guix users can run the interactive function `guix-apply-manifest'
instead.]

When there is a package without substitutes, I will stop the command,
comment out the said package and re-run the command. I will also re-try
after a few days when more substitutes are available.

Hope this help!

Cheers,
Alex

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Is there a way to upgrade only packages with substitutes?

[Katherine Cox-Buday]

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

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

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

Hello Katherine,

Katherine Cox-Buday writes:

> 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?

I don't think there is an option for this. It would certainly be helpful
if there were one.

Currently, my workaround is to create a manifest listing packages to be
installed:
https://notabug.org/alexvong1995/guix-package-declaration/src/master/manifest
and run "guix package -m ./manifest" instead of "guix package -u".

[emacs-guix users can run the interactive function `guix-apply-manifest'
instead.]

When there is a package without substitutes, I will stop the command,
comment out the said package and re-run the command. I will also re-try
after a few days when more substitutes are available.

Hope this help!

Cheers,
Alex

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[znavko]

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 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

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

[Katherine Cox-Buday]

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?).

Yes, sorry, I think I have given the impression that I have had no way
of working around this; I do, and I have. It is just an inconvenience.

Usually what I do is that when I come upon a package that will take a
long time to build, I kill the upgrade, pass the package to
`--do-not-upgrade`, and continue.

> 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 think this can be done with guix features but this is hard work, not
> for usual users.
> And sure guix must have this feature.

Yes, I think it would be better for users, and on Guix's infrastructure.

-- 
Katherine

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

[L p R n d n]

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

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

[znavko]

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

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

[P]

> 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.

How can you know what compiles quickly? Stats based on previous versions? What if someone is bound more by memory and/or storage than time?