bug#74790: [PATCH] gnu: librewolf: Support Guix icecat browser extensions.

[Hilton Chain <hako@ultrarare.space>]

Hi!

I have applied the patch as 396eb759d4a7be6756c1460c52067d320673859f.

On Sat, 14 Dec 2024 02:15:11 +0800,
Clément Lassieur wrote:
>
> [1  <text/plain; utf-8 (quoted-printable)>]
> Hi Ian,
>
> On Fri, Dec 13, 2024, at 6:38 PM, Ian Eure wrote:
> > The patches look good to me, thank you for taking this on!  How to
> > handle browser extensions is a subject that’s been on my mind
> > intermittently, so it’s great to see effort in that direction.
> >
> > I think it might be non-obvious that IceCat packages affect
> > non-IceCat browsers.  I’d really like to have a solid facility for
> > managing extensions across the different Firefox forks, either
> > with generic "browser-extension-ublock-origin" packages; or

There're also chromium extensions using same sources but with a different build
process.  So to use generic names I think one approach is to use both build
processes in one package and use output names for distinction, but it'll be
harder to find all available extensions, for example currently via
‘guix search "\-icecat$"’.

> > something similar to the Common Lisp setup, where
> > implementation-specific package variants can be derived from a
> > canonical one.
>
> I've looked into having variant-specific extensions already
> (https://issues.guix.gnu.org/68298), and I came to the conclusion that it
> added a lot of complexity for little benefits.  Maybe I was wrong and you
> thought of a better implementation?  Still, I think most of the time users
> would want their "system add-ons" to be available on all browsers.  When this
> is not the case, they can already use 'guix shell' to run a Firefox variant
> with a different set of extensions, or use the built-in add-on system.
>
> We can however add clarity where things are unclear.

Agree, we can document that extensions are also available for our web browsers,
with name -chromium for ungoogled-chromium and -icecat for Firefox-based ones.