Native packages as a distribution model

[Masgalor]

I'd like to start a discussion about the topic "distribution".
I'm sure the way this is done right now is not the final plan, so I'd like to learn how the ideal solution would look like.
I mean publishing build-artifacts so the user has to download them and put those files by hand in the right place is not that convenient.

I for one really like native packages if the maintainer takes the time to build high quality packages for their software the user only has to add a repository and hit "install" and that's it. Maybe it is not surprising that I'm packing some software projects for *deb and *rpm distros. So, the first thing I did after trying out burrito was to write a package recipe for Tumbleweed.

You can look it up here if you care: https://build.opensuse.org/package/show/home:Masgalor:Burrito/burrito
It will install everything to /opt/burrito and place a desktop file in /usr/share/applications/burrito.desktop, so everything the user needs to do is creating a link for the dll. Like ln -s /opt/burrito/link/d3d11.dll <path_to_gw2>/arcdps_burritolink.dll.
Now Burrito can be launched from the application drawer like every other application and the package-manager will automatically take care of updates and such.

If you want to know more about packaging software or if you have other plans to create an easier installation process and need some help let me know. In my experience an easy installation is the best way to get someone to try out new software.

[AsherGlick]

I too like packages, they make a lot of stuff easier, but it is not on our roadmap right now for burrito.

One thing that deb/snap/flatpack/rpm/etc packages are really bad at is not knowing where other files are. They are good at dependency management and making sure known paths exists, but adding gw2 as a dependency might be overkill. That <path_to_gw2>/arcdps_burritolink.dll could be any number of values from lutris, to bottles, to steam, to manual wine installs, etc. It could even be <path_to_gw2>/d3d11.dll, or even more it could not exist at the time of installation. This means that the user is going to be dragging an dropping/symlinking files anyways.

Either that or a new workflow needs to be added within burrito to identify where the d3d11.dll file should be copied to. That workflow would also need to take into account any other mods that the gw2 user might be using as to not interfere with those programs workflows. Be it arcdps, modloader, or something else entirely.

Burrito is open source under the GPL so there is nothing really wrong with you repacking it for distribution. In fact, the point of open source software is that you CAN do that. And I am happy to link to your repackaging as a 3rd party repackage.

If all we care about is a .desktop launcher I think that would be a much simpler feature. All you need to know in order to automatically make one of those is the path of burrito, and burrito already knows its own path. So a button somewhere for "add launcher" or something of that nature could be possible. But I wont accept any PRs that change the menu stuff too much right now because xml_converter has a bunch of changes that might conflict with anything like that. So any feature to do that would have to be after we merge xml_converter.

[Masgalor]

My primary intention is giving potential users an easier way to use burrito.
Imho burrito is a good example for extraordinary good software that has a low adoption rate because the installation instructions scare everyone away. There are so many conversations online that go like, I'm running gw2 on linux now, are there any working overlays. ... Mh no, not really, you could try burrito. ... Oh, yeah I heard of that. But I couldn't make it work and gave up on it. Especially now with the steady rising market share of the steam deck whose users not even know what linux means.

Burrito is open source under the GPL so there is nothing really wrong with you repacking it for distribution.
In fact, the point of open source software is that you CAN do that.

Yeah, sure I can do this but the question is rather, why would I do this. The distro isn't paying me to package it nor does it care if the package exists, the same is true for ANET/GW2 and if the author/team also doesn't care why would I spend so much time on packages I myself don't even need. I'm happy to help with packaging or to manage third party packages but it would be a giant waste of time if those packages wouldn't be seen as the main distribution model and have appropriate backing by the development team.

Regarding that symlink-topic, my point was not to solve this problem with the package, I'm aware it is not possible. What I tried to say was if that symlink was created once the underlying files could be updated automatically without any user input at all.

If I had to come up with a workflow to ease the symlink creation I'd do the following:

• Put a file in the base directory of burrito or even better in ~/.config/burrito (to survive uninstall/reinstall) that holds the path to GW2_64.exe.
  • If this file does not exist/is empty/has an invalid path when starting up burrito, open a dialog/fileselector and ask the user to point it to GW2_64.exe.
  • If we have a valid path to the executable check if the file d3d11.dll is present.
    • If it is not, create a symlink with that name.
    • If it is, we can assume with a high chance that the user is either using arcdps or modloader.
      So we create two symlinks, one to arcdps_burritolink.dll and one to gw2addon_burritolink.dll.

We would obviously need a way to reset or disable this feature but this can be handled inside the ui I guess.

Sidenote: If we would manage to bring burrito to flathub.org it would be the one and only overlay that can be natively installed on the steam deck, the biggest platform for linux gaming that ever existed.

[AsherGlick]

There are so many conversations online that go like, I'm running gw2 on linux now, are there any working overlays. ... Mh no, not really, you could try burrito. ... Oh, yeah I heard of that. But I couldn't make it work and gave up on it.

From our data this is not primarily due to a poor install process, but a poor compatibility with various display managers, and of course Wayland. Increasing the out-of-the-box compatibility with other graphics configurations is on our roadmap. We did find that configuring burrito_link.exe was a pain, involving figuring out environment variables and whatnot. But since we made an alternate form of burrito link as an injected library that has been the primary vehicle of choice.

Additionally better integration into the existing environments is crucial, auto-updating the size of the overlay, moving the overlay inline with the gw2 window, and removing the always-on-top flag of the overlay when the gw2 window is not in focus are all things that could help new users.

Yeah, sure I can do this but the question is rather, why would I do this.

Only because you want to! If you don't want to then please dont feel pressured to do so. We only have so much time on our hands and it is important to use it in the way we think is best.

Sidenote: If we would manage to bring burrito to flathub.org it would be the one and only overlay that can be natively installed on the steam deck, the biggest platform for linux gaming that ever existed.

Definitely, the steam deck is a target on our horizon. But I have not yet gotten a good controller configuration with gw2 on my steam deck yet, and until I figure that out I doubt I will be championing the steamdeck integration myself.

Please keep in mind that I am not writing packages off forever, like I said earlier: I really like them. However they are just not the highest priority right now vs other features (like those mentioned above, supporting the other taco/blishhud attributes, and #103) and wont be able to get adequate design considerations from our limited resources. I dont want to commit to maintain something I am not confident about the design of.