Strange behaviour when cleaning up "/share/locale"

[a-andre]

Take the following example org.test.test.json file

{
    "app-id": "org.test.test",
    "runtime": "org.gnome.Platform",
    "runtime-version": "3.28",
    "sdk": "org.gnome.Sdk",
    "modules": [
        {
            "name": "testA",
            "cleanup": [
                "/share/locale"
            ],
            "buildsystem": "simple",
            "build-commands": [
                "mkdir -p /app/share/locale/es",
                "touch /app/share/locale/es/testA.mo"
            ]
        },
        {
            "name": "testB",
            "buildsystem": "simple",
            "build-commands": [
                "mkdir -p /app/share/locale/es",
                "touch /app/share/locale/es/testB.mo"
            ]
        }
    ]
}

Running $ flatpak-builder dir --repo=repo org.test.test.json creates the directories dir/files/share/runtime. But there is no dir/files/share/locale/es/testB.mo.

After removing the cleanup part flatpak-builder creates dir/files/share/locale/es/test{A|B}.mo as expected.

It only happens for /share/locale, maybe because it is treated special.

[chrisawi]

With separate-locales enabled, /app/share/locale/*/ are moved and replaced with symlinks during the build phase. If I'm reading the code correctly, the first module to create a locale dir ends up 'owning' that symlink.

When cleanup runs, it will naively remove the symlinks owned by the module if they match the pattern, even if their targets contain message catalogs from other modules.

I wonder if it would be feasible to delay locale migration until after cleanup.

[skierpage]

I think this is causing skrooge bug 476591, wherein the symlinks in /app/share/locale/ are missing for several locales that have translations. I added cleanup properties to several of its library modules because otherwise they put a lot of irrelevant binaries and docs in the flatpak.