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

[Tomas Volf <~@wolfsden.cz>]

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

On 2024-01-18 17:59:23 +0000, Fredrik Salomonsson wrote:
> 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

Especially for cases like this, just having your fork into which you
periodically merge from upstream works fairly well.  You can apply the patch
directly to the fork without waiting for upstream to act, and git is smart
enough to handle the merge well.

Creating the fork is bit involved, since guix git authenticated is designed in a
way to make authenticated forks pretty much impossible (assuming you want to git
merge), but after the initial setup (for which scripting exists) there really is
not much work required to maintain it (just occasionally merging the upstream).

So that seems like your best option (and what I do).

Have a nice day,
Tomas Volf

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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