fix(build): sur Linux, ne vendoriser que le SDK ffmpeg

Deux collisions dans electron/native/bin/linux-x64/, introduites en branchant
fetch:ffmpeg sur build:linux.

La première a cassé le build : le CLI statique est vendorisé sous le nom
`ffmpeg` (un FICHIER), alors que build-linux-pipewire-helper.mjs y crée un
RÉPERTOIRE `ffmpeg/` — le nom contre lequel le RUNPATH $ORIGIN/ffmpeg du
helper est compilé. D'où `EEXIST: mkdir .../linux-x64/ffmpeg`.

La seconde n'avait pas encore frappé et aurait été pire à diagnostiquer : les
copies runtime des .so partaient elles aussi dans ce répertoire, NON renommées,
sous les mêmes noms que les copies à symboles renommés (osff_*) qu'y place
build-linux-compositor-addon.mjs pour que l'addon ne se lie pas au ffmpeg de
Chromium. L'une aurait écrasé l'autre, et l'addon serait mort au chargement.

Ce répertoire appartient donc aux deux scripts natifs ; fetch-ffmpeg n'a rien à
y faire sur Linux. La copie runtime est restreinte à Windows, où le loader
cherche bien les DLL à côté de l'exécutable, et `--sdk-only` (nouveau script
fetch:ffmpeg:sdk) saute le CLI statique. Le SDK, lui, reste nécessaire :
pipewire-capture et l'addon compositeur linkent contre lui.

Le CLI n'est pas une perte : assertLgpl note que plus rien dans l'app ne lance
ffmpeg, et v1.7.0 livrait AppImage/deb/pacman sans.

Vérifié depuis un état vierge sur Linux : les cinq bibliothèques que build.rs
demande sont résolvables, les en-têtes sont en place, et le chemin
linux-x64/ffmpeg est libre pour le mkdir du helper.

Author: EtienneLescot

package.json

@@ -36,7 +36,7 @@
 		"build:native:linux": "node scripts/build-linux-pipewire-helper.mjs",
 		"build:win": "npm run build:native:win && npm run fetch:ffmpeg && npm run build:native:compositor && tsc && vite build && electron-builder --win --config.npmRebuild=false",
 		"build:win:store": "npm run build:native:win && npm run fetch:ffmpeg && npm run build:native:compositor && tsc && vite build && electron-builder --win appx --config.npmRebuild=false",
-		"build:linux": "npm run fetch:ffmpeg && npm run build:native:linux && npm run build:native:compositor:linux && tsc && vite build && electron-builder --linux AppImage deb pacman --config.npmRebuild=false",
+		"build:linux": "npm run fetch:ffmpeg:sdk && npm run build:native:linux && npm run build:native:compositor:linux && tsc && vite build && electron-builder --linux AppImage deb pacman --config.npmRebuild=false",
 		"build:whisper-binaries": "bash scripts/build-whisper-stt.sh",
 		"test:whisper-stt": "node scripts/test-whisper-stt.mjs",
 		"test": "vitest --run",
@@ -66,7 +66,8 @@
 		"test:e2e:windows-native-checklist": "playwright test tests/e2e/windows-native-checklist.spec.ts",
 		"prepare": "husky",
 		"fetch:ffmpeg": "node scripts/fetch-ffmpeg.mjs",
-		"fetch:ffmpeg:mac": "node scripts/fetch-ffmpeg-macos.mjs"
+		"fetch:ffmpeg:mac": "node scripts/fetch-ffmpeg-macos.mjs",
+		"fetch:ffmpeg:sdk": "node scripts/fetch-ffmpeg.mjs --sdk-only"
 	},
 	"dependencies": {
 		"@fix-webm-duration/fix": "^1.0.1",

scripts/fetch-ffmpeg.mjs

@@ -387,9 +387,11 @@ async function fetchSharedDlls(tag, binDir) {
 
 	// probe for any previously vendored DLL by name; re-download is driven by
 	// --force same as the static exe, checked once we know what we'd extract.
-	const alreadyVendored = fs
-		.readdirSync(binDir, { withFileTypes: true })
-		.some((e) => e.isFile() && isSharedLib(e.name) && /^(lib)?av/i.test(e.name));
+	const alreadyVendored =
+		process.platform === "win32" &&
+		fs
+			.readdirSync(binDir, { withFileTypes: true })
+			.some((e) => e.isFile() && isSharedLib(e.name) && /^(lib)?av/i.test(e.name));
 	// The build-time SDK comes out of this same archive, so a tree that has the
 	// DLLs but not the SDK must still re-download — otherwise we skip here and
 	// the compositor build fails afterwards on the missing FFMPEG_DIR.
@@ -426,21 +428,33 @@ async function fetchSharedDlls(tag, binDir) {
 		const libs = findSharedLibs(tmp);
 		if (libs.length === 0) throw new Error(`No shared ffmpeg libraries found inside ${spec.asset}`);
 
-		fs.mkdirSync(binDir, { recursive: true });
-		for (const lib of libs) {
-			// Linux ships symlink chains (libavcodec.so -> .so.62 -> .so.62.x). Follow
-			// them: copyFileSync would dereference into three identical large files, and
-			// a dangling link would break the loader outright.
-			const dest = path.join(binDir, path.basename(lib));
-			const st = fs.lstatSync(lib);
-			if (st.isSymbolicLink()) {
-				fs.rmSync(dest, { force: true });
-				fs.symlinkSync(fs.readlinkSync(lib), dest);
-			} else {
-				fs.copyFileSync(lib, dest);
+		// Windows only. There, the loader finds a DLL next to the .exe, so the runtime
+		// copies belong in binDir. On Linux that same directory is owned by the two
+		// native build scripts: build-linux-compositor-addon.mjs puts SYMBOL-RENAMED
+		// (osff_*) copies there so the addon cannot bind to Chromium's ffmpeg, and
+		// build-linux-pipewire-helper.mjs stages unrenamed ones in `binDir/ffmpeg/`
+		// for the helper's `$ORIGIN/ffmpeg` RUNPATH. Dropping a third, unrenamed set
+		// in binDir would overwrite the renamed ones under identical filenames and
+		// break the addon at load time. Linux takes the SDK below and nothing else.
+		if (process.platform !== "win32") {
+			console.log(`Skipping runtime copies into ${binDir} (owned by the native build scripts).`);
+		} else {
+			fs.mkdirSync(binDir, { recursive: true });
+			for (const lib of libs) {
+				// Linux ships symlink chains (libavcodec.so -> .so.62 -> .so.62.x). Follow
+				// them: copyFileSync would dereference into three identical large files, and
+				// a dangling link would break the loader outright.
+				const dest = path.join(binDir, path.basename(lib));
+				const st = fs.lstatSync(lib);
+				if (st.isSymbolicLink()) {
+					fs.rmSync(dest, { force: true });
+					fs.symlinkSync(fs.readlinkSync(lib), dest);
+				} else {
+					fs.copyFileSync(lib, dest);
+				}
 			}
+			console.log(`Vendored ${libs.length} shared librar(ies) -> ${binDir}`);
 		}
-		console.log(`Vendored ${libs.length} shared librar(ies) -> ${binDir}`);
 		if (sdkDest) vendorFfmpegSdk(tmp, sdkDest);
 		console.log("LGPL verified: safe to ship with an MIT app.");
 	} finally {
@@ -469,6 +483,19 @@ async function main() {
 	const binDir = path.join(ROOT, "electron", "native", "bin", tag);
 	const dest = path.join(binDir, spec.exe);
 
+	// `--sdk-only` skips the standalone ffmpeg CLI and vendors just the build-time
+	// SDK. Linux needs it: the CLI lands at `<binDir>/ffmpeg` as a FILE, while
+	// build-linux-pipewire-helper.mjs stages the helper's libraries into
+	// `<binDir>/ffmpeg/` as a DIRECTORY — the name its `$ORIGIN/ffmpeg` RUNPATH is
+	// compiled against. One clobbers the other (`EEXIST: mkdir .../linux-x64/ffmpeg`).
+	// Nothing in the app spawns the CLI any more (see assertLgpl's note), and v1.7.0
+	// shipped Linux packages without it, so on Linux it is dead weight AND a conflict.
+	if (process.argv.includes("--sdk-only")) {
+		console.log(`Skipping the standalone ffmpeg CLI (--sdk-only).`);
+		await fetchSharedDlls(tag, binDir);
+		return;
+	}
+
 	if (fs.existsSync(dest) && !process.argv.includes("--force")) {
 		console.log(`Already present: ${dest}`);
 		console.log(assertLgpl(dest));