Re: Best practice when dealing with a broken package for guix home?

[Fredrik Salomonsson]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On mar., 16 janv. 2024 at 18:41, Felix Lechner via <help-guix@gnu.org> wrote:
>> On Tue, Jan 16 2024, Fredrik Salomonsson wrote:
>>
>>>  Or how do you deal with cases when they happen?
>>
>> I maintain a custom Guix with patches on top, plus my own channel.
>
> Well, for what it is worth, I think the good practise is to send
> contributions when something broken on master is fixed and not keep the
> fix in your own patched Guix version.

Agreed.  I should have probably worded my initial question a bit better.
I assumed that the package has already been reported by either myself or
someone else and that patches for it to be fixed was already submitted.
What prompted me to ask this question was [mpv-mpris][0].  Since it's
been broken since at least Dec 26 2023 and is the one that is holding up
my upgrade.  And I'm not trying to single anyone out, I totally
understand things take time especially during holidays.  I just got
thinking if there is a good practice to workaround it while I wait for
it to be fixed.  As doing any of my usual workarounds would require a
bit of work as it was mpv that changed and broke mpv-mpris.

[0] https://issues.guix.gnu.org/68044

> That said, I do not use “guix home” so my way probably does not make
> sense.  What I do is that I have separated manifest files.  For
> instance, I have emacs.scm for my Emacs stuff, ocaml.scm for my OCaml
> stuff, compiler.scm for some compilers that I use, base.scm for all the
> basic stuff as coreutils etc.
>
> When one package is broken, it impacts only one manifest.  So it
> mitigates the issue for upgrading.

I did this before, and while it did helped reduce the impact of a broken
package.  It did complicate my upgrade as I needed to have my own update
script etc.  What I like with guix home is that it can essentially
reproduce my home environment on any of my machines by both installing
the packages needed and configuration.  Which is a huge time saver as I
had the issue when I used Arch that I never really got my home
environment to work the same on my desktop and laptop.

>
> What I am not fully happy is that “guix weather” does not have a
> codified exit status.  It had been discussed [1] but no consensus.  It
> would ease:
>
>   guix weather -m path/to/manifests/foo.scm \
>     && guix upgrade -p path/to/profiles/foo
>
> Cheers,
> simon
>
>
> 1: guix weather exit status?
> Leo Famulari <leo@famulari.name>
> Thu, 08 Jul 2021 16:35:03 -0400
> id:YOdhd7FfMOvKjTQe@jasmine.lan
> https://lists.gnu.org/archive/html/guix-devel/2021-07
> https://yhetil.org/guix/YOdhd7FfMOvKjTQe@jasmine.lan

Didn't know that about guix weather.  I don't really use it that much as
my desktop is generally powerful enough to just chew threw packages that
lacks substitutes.  And I usually starts by upgrading that before moving
on to my laptop and other machines running guix.

-- 
s/Fred[re]+i[ck]+/Fredrik/g