Splitting the Linux NuGet packages because they are growing

[mattleibow]

Hello Good Skia-ple!

I see we are almost 30MB with our NuGet package on NuGet.org: https://www.nuget.org/packages/SkiaSharp.NativeAssets.Linux/3.118.0-preview.2.3

And we seem to be adding more:

• Add riscv64 build support #3192 adds RISC V builds for x64 glibc
• Extend clang-cross to support alpine #3200 adds 2 RISC V builds for musl (x64 and arm64)
• Add LoongArch64 build support #3198 adds 2 Loongarch64 for glibc and musl
• [FEATURE] linux-bionic flavor of libSkiaSharp and libHarfBuzzSharp #3206 is a request for bionic...
• [FEATURE] Prebuilt ARM libraries for Alpine Linux #3097 wants musl + arm64

At some point (not sure which) we will reach a large package size. We can still keep this big packaged to bring it all in, but are there thoughts on having separate packages?

Not sure if we should split on glibc/musl, or if we should go with arch (x64, arm, riscv). Or both. Or more like (debian, alpine, bionic).

Do we have any standards or general trends out there?

[mattleibow]

Seems NuGet has a feature to allow for splitting a nuget on RID and then bringing it all together:

couldn't find a better example, but here's one: https://nuget.info/packages/NtvLibs.cuda11.cublasLt64_11.runtime.json/11.8.0

you package a file called runtime.json in the root of the package, and that file has a structure like:

{
 "runtimes": {
   "<rid>": {
    "<package id>": {
       "<rid-specific package id>": "<rid-specific package version>"
   }
  }
}

This may also make things like the runtime assets be less annoying and we can just include the linux things by default - and we will be able to magically get everything

[4Darmygeometry]

Hello Good Skia-ple!

I see we are almost 30MB with our NuGet package on NuGet.org: https://www.nuget.org/packages/SkiaSharp.NativeAssets.Linux/3.118.0-preview.2.3

And we seem to be adding more:

• Add riscv64 build support #3192 adds RISC V builds for x64 glibc
• Extend clang-cross to support alpine #3200 adds 2 RISC V builds for musl (x64 and arm64)
• Add LoongArch64 build support #3198 adds 2 Loongarch64 for glibc and musl
• [FEATURE] linux-bionic flavor of libSkiaSharp and libHarfBuzzSharp #3206 is a request for bionic...
• [FEATURE] Prebuilt ARM libraries for Alpine Linux #3097 wants musl + arm64

At some point (not sure which) we will reach a large package size. We can still keep this big packaged to bring it all in, but are there thoughts on having separate packages?

Not sure if we should split on glibc/musl, or if we should go with arch (x64, arm, riscv). Or both. Or more like (debian, alpine, bionic).

Do we have any standards or general trends out there?

Since the glibc library is used by most Linux distributions, while the musl library is only used by a few Linux distributions such as Alpine Linux, bionic library is used by Android, I suggest splitting the content of the SkiaSharp.NativeAssets.Linux package into three packages: SkiaSharp.NativeAssets.Glibc, SkiaSharp.NativeAssets.Musl and SkiaSharp.NativeAssets.Bionic. The SkiaSharp.NativeAssets.Linux package itself should be changed to a meta-package, which can be used to install both SkiaSharp.NativeAssets.Glibc, SkiaSharp.NativeAssets.Musl and SkiaSharp.NativeAssets.Bionic simultaneously. The same applies to the HarfBuzzSharp.NativeAssets.Linux package.