Re: Suggestion: No more language packs for macOS as they are fundamentally broken

[Jan-Marek Glogowski <glogow@xxxxxxxxxx>]

Am 15.06.20 um 11:33 schrieb Tor Lillqvist:
> (Sorry, my fingers slipped somehow and my previous reply had no of my
> own text.)
> 
>     4) create a real macOS installer package (native macOS installer
>     program, not a runnable script like the langauge pack "installer"),
>     similar to the windows msi that allows to customize the installation
>     and pick the components you want.
> 
> 
> But where would such a "real" installer install the optional parts? Into
> the app bundle? Is it possible to leave out optional parts from a signed
> and notarized app bundle, if done by an installer? I honestly don't
> know. But my guess would be no, that leaving things out from the signed
> app bundle is no different from adding files to it later (as the
> language packs now do).
> 
> Sure, such an installer could instead put the optional parts in for
> instance /Library or ~/Library. But then we are back at the problem I
> already wasted a couple of weeks on: Teaching the LO code in various
> places to look up various things (message catalogs, extensions,
> autotexts, dictionaries, help, whatnot) in multiple locations. Which
> seems quite hard. At least to me, but somebody else who understands the
> code better might do it in a day, of course.

Maybe that complicated, multi-directory lookup is not needed. Quoting
from "Technical Note TN2206 - macOS Code Signing In Depth"[1]:

= Changes That Don't Invalidate a Code Signature =

There are a few changes you can make to a signed bundle that won't
invalidate its signature.

If you have optional or replaceable content you wish to change without
invalidating the code signature, nested code can be replaced with
equivalent (conforms to the designated requirement) nested code without
disturbing the outer signature. This is the design mechanism for
indirection in code bundles. It is acceptable to code-sign a bundle
containing no main executable, and then treat it as nested code
(typically in Contents).

Removing files from .lproj directories inside Contents/Resources will
not invalidate the code signature, but adding or changing files will.

-----------------

So if I understand this correctly, then maybe we can pre-register all
the language pack content in the main "installer" / app and in the end
the language pack "installers" would work like re-adding files to the
"Contents/Resources"?

[1]
https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG402

P.S. I neither have a Mac nor any possibility to verify this
interpretation. I was just searching for "apple macos code signing
optional parts" and this came up.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice