[bug#67512] [PATCH v4 3/4] gnu: Add wasm packages.

[Clément Lassieur]

On Wed, Feb 21 2024, Liliana Marie Prikler wrote:
> Am Dienstag, dem 20.02.2024 um 18:18 -0800 schrieb Ian Eure:
>> Clément Lassieur <clement@lassieur.org> writes:
>> 
>> > > Are you saying you want a process like:
>> > > 
>> > > 1a. Get wasm toolchain stuff merged.
>> > > 1b. Get Librewolf merged without WASM sandboxing.
>> > > 2. Update icecat, torbrowser, mullvad, and librewolf to use 
>> > > WASM sandboxing.
>> > 
>> > Excatly.  1b can be done after 1a, or before 1a.
>> > 
>> 
>> Is there a technical reason why landing WASM sandboxing support 
>> for all browsers in the same patch is desirable?  I can intuit 
>> none, and as I’m disinclined to either roll back portions of my 
>> existing patchset, or work on other browsers, the proposal is 
>> disagreeable.
> I think this ordering is w.r.t. *patch sets*, not patches.  I wouldn't
> suggest dropping four packages into one patch.

Indeed I've never said it should be done in one patch.  I said one-shot
as in ‘symmetrical’: the work required to add Wasm to our browsers
should be more or less the same for all browsers, and code duplication
should be avoided.

>> I’m fine with splitting off the WASM toolchain stuff into a 
>> separate patch, and then merging LibreWolf afterwards.  If others 
>> would like to add WASM sandboxing to their Firefox-derived 
>> browsers afterwards, they are, of course, welcome to.

My point is that we need to understand the diff between a browser
without wasm, and a browser with wasm.

If you add librewolf with wasm already included, we don't have that diff
info.  And it's harder for us reviewers to understand what in your patch
is wasm specific.  And it's harder for us to include wasm to our firefox
based browsers.

I acknowledge it's more work for you, but it's a work that would have to
be done otherwise by the reviewer, at least to test the wasm stuff.

>> Is there further guidance on where the WASM toolchain packages 
>> should be placed?  It seemed there was objection to having them in 
>> (gnu packages wasm), but nobody has proposed an alternate location 
>> or engaged with the options I presented.
> Unless there's a strong reason not to, I'd place them among the
> existing ones in (gnu packages web).
>
> WDYT?

Agreed.