1107628 - (l10nrepacks) Make l10n repacks not as much of a disaster as they currently are

Status: NEW

(Release Engineering :: Release Automation: L10N, defect)

Description

[(not currently active) Ted Mielczarek]

Right now l10n repacks are very complicated and fragile and nobody has a good understanding of how all the bits work. We had a meeting today about how we can fix that, and I think we all agreed on a set of steps (which I will file as bugs):
1) Create a mach command that encapsulates all the steps necessary to take an en-US build and a set of locales and produce repacked builds in those locales.
2) Change the RelEng repack invocation to use that mach command (via mozharness) instead of the tangle of commands it currently uses.
3) Rewrite the mess of make logic that actually does the repacking into a simple Python script. It's not doing a lot of hard work, it's just doing it in a weird way tied into the build system.

Please correct me if I've misrepresented any of the takeaways from that meeting (also please CC anyone that's interested that I left out).

Comment 1

[(not currently active) Ted Mielczarek]

I was writing this in a comment in another bug, but I think it's too much detail for that bug, so I'm going to put it here since I took the time to write it:

Repacks run configure, make a few little bits, and then run `make installers-ab-cd` in $objdir/browser/locales for each locale they repack (this is for desktop, mobile is similar):
https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/testing/mozharness/scripts/desktop_l10n.py#859

The `installers-%` target then depends on a bunch of other targets:
https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/browser/locales/Makefile.in#163

One of which is the `langpack-%` target defined in toolkit/locales/l10n.mk:
https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/toolkit/locales/l10n.mk#211

...which in turn depends on the `libs-%` target:
https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/browser/locales/Makefile.in#92

...which runs make in a bunch of directories, overriding $(AB_CD) to get them to copy localized files to the right places.

Comment 2

[Axel Hecht [:Pike]]

Note, the dependencies right now are flawed, they're trying to make things happen in order, which they don't.

I set most of that straight in bug 1385227, but that failed with the windows installer bits.

The zip packages up `firefox` as root, and the installer uses `core`, which I haven't figured out. http://searchfox.org/mozilla-central/source/toolkit/mozapps/installer/packager.mk#23 is where it does that in the packaging logic for the en-US build.

Comment 3

[Axel Hecht [:Pike]]

Also, for multi-locale builds, we have the chrome-% target which is the same thing as libs-% w/out the XPI_NAME. We should be able to get along with just one of the two now, and pass around XPI_NAME always, potentially empty.