add: xivlauncher

[reiichi001]

XIVLauncher.Core 1.3.1, compiled on the user's machine. Another port from my old MPR packages, hopefully with less first-time issues after working on xivlauncher-bin.

This is a little harder for me to test for Debian, as I'm primarily using Ubuntu via WSL. I had to build with -Ns so it could reach NuGet. Dotnet 10 is fairly new and may not be in all APT repositories, but I'm not sure if I can set a depends for dotnet 9.0 or later, since the Ubuntu packages include versioning in their package names. Otherwise, 9.0 and later will work, but 10 is the current LTS, which is why I've gone for that here.

[Elsie19]

Dotnet 10 is fairly new and may not be in all APT repositories, but I'm not sure if I can set a depends for dotnet 9.0 or later, since the Ubuntu packages include versioning in their package names

You could do:

depends=(... "dotnet-9.0 | dotnet-10.0")

Or whatever the versioning scheme is!

[reiichi001]

Dotnet 10 is fairly new and may not be in all APT repositories, but I'm not sure if I can set a depends for dotnet 9.0 or later, since the Ubuntu packages include versioning in their package names

You could do:

depends=(... "dotnet-9.0 | dotnet-10.0")

Or whatever the versioning scheme is!

It's a similar case for dotnet 9 as well. On this front, I'm considering checking if it's in the user's path and if not, to grab it on demand, as Microsoft does provide it in a mostly portable manner. (This isn't ideal, but it's that or try to inject adding an apt repository on Debian, which I feel would be worse. The resulting binary is self-contained during build, so it does not rely on the user having the runtime installed in order to run the program, thankfully.)

The bigger concern is getting access to NuGet in CI, as that has to be fetched online/on-demand, to my knowledge. (I can't quite bundle those in advance unless this can be done in the prepare() stage. I can test that out). Otherwise, is there an option to build outside the sandbox by default?

I saw one of the CI failures was because libxml2 could not be installed, which is...strange, given that it should be present just about anywhere that a Gnome or GTK application can be built. Or any web browser. I might have to tackle that one later.

I'll work on updating the PR to get checks to pass. ...this is probably going to be the worst of any submissions to get up and running, as anything after that can mostly use learning from here for CI fixes.

[reiichi001]

I think I've got a workaround to pulling in dotnet handled, which builds/tests fine locally, but needs the No Sandbox option. Since Debian does not provide dotnet in its repository, and Ubuntu might, but might also provide an old version, setting it up for the build environment is probably the best way to go for cross-distro support.

Unfortunately, I see the sandbox will complicate this, somewhat, as that means I cannot pull dotnet or restore NuGet packages. (C# depdencies. Modern dotnet is handy for cross-platform code, but is not well suited to offline build environments.)

I'm not sure if there's a way to ask CI to run without the sandbox, or if that's something I can set in the pkgbuild as users would also need to run as pacstall -I xivlaucher -Ns too.