Packaging Airshipper: Fedora Perspective

[Frinksy]

Is your feature request related to a problem? Please describe. Currently, packaging Airshipper as an RPM for Fedora is not as straightforward as it could be. Fedora provides Packaging Guidelines and specific ones for Rust packages. Although there is no requirement to respect these guidelines when creating a Copr repository (Cool Other Projects / Community Projects), following them helps a great deal in making packaging easier.

Describe the solution you'd like

• Separate the client and server into 2 separate repositories: Currently the source for both the client and server components are situated on the same repository. Using macros provided specifically for packaging Cargo-based packages do not work.

• Use crates.io as the source for dependencies: Fedora packages are preferably compiled against system libraries. Macros are provided to achieve this, but only Rust libraries published on crates.io are packaged for Fedora.

• Use the latest published versions of all dependencies: The latest versions of dependencies are more likely to already be packaged for Fedora. However, iced is one of the packages not available at all yet. (Possibly the last one left for this project?)

• Remove nightly features: I suppose this could be in a separate branch if required, but nightly features are not supported when packaging an RPM for Fedora. (Packages must be built using the distribution's version of cargo and rustc, rustup is not available)

• Add .desktop file and PNG/SVG icon: Currently, my package of Airshipper uses a patch file to add a .desktop file, and uses a second source to get a icon. Getting them directly from the repository would simplify things.

Describe alternatives you've considered Alternatively, I could maintain the RPM package in the same way as it is packaged now.

Additional context This was mostly a description of my point of view as a Fedora user, rather than demands. I would be happy to help with any of the aforementioned changes :smiley:

I am not sure what the long-term plan for Airshipper is, or if its functionality / purpose will change. In its current state, it is not suitable to be accepted into official Fedora repositories, as it "downloads code bundles from the internet in order to be functional or useful". Alternative, third-party repositories such as RPMFusion might be more inclined to including Airshipper.

[Songtronix]

Separate the client and server into 2 separate repositories

Would really dislike doing this imo as server and client changes often have to happen together. Although I can see it changing once the server api satisfy basic needs and things stablize.

Use crates.io as the source for dependencies

Publishing airshipper on crates.io would require it anyway and I'm in favor of using crates.io whenever possible. Blocking dependencies are:

• clap (could already be released?)
• iced (might take a while for another release)
• rocket (0.5 should be coming soonish)

Use the latest published versions of all dependencies

Always a good goal. When I release a new version I often update the deps too. Have to see how to deal with iced incase of Fedora.

Remove nightly features

Was blocked by rocket but master (and with it the coming 0.5 release) supports stable and nothing would stop airshipper from going stable. I see no benefit in using nightly right now anyway.

Add .desktop file and PNG/SVG icon

Recently introduced git lfs so adding pngs/svg is a no brainer. It's a matter of organization for me like where to exactly put it and how to organize all the package specific files but no big issues with maintaining them in the repo.

[Frinksy]

About dependencies: I see clap has a new beta release, iced v2.0 is released (from what I see it includes the commit referenced in Cargo.toml, but I may be wrong). I've been playing around in a branch and I have got the client working with these :smiley: https://github.com/Songtronix/Airshipper/compare/master...Frinksy:Frinksy/dependencies I've only tested it on Linux though, and I have no idea if there are breaking changes on Windows.

[jcgruenhage]

I stumbled over this while trying to package Airshipper for Void Linux, and I have similar problems as @Frinksy has over at Fedora, but it's a bit different in some cases, so I think maybe my input here would be helpful as well:

• Separate the client and server into 2 separate repositories

  I don't think that this should be something we require from application developers. Airshipper is one cargo workspace, with client and server being projects in that workspace. With the amount of projects using workspaces increasing (which has valid reasons IMO), I think we should work on our distro tooling/macros to support workspaces properly, instead of avoiding workspaces in projects.

• Use crates.io as the source for dependencies

  and

  Use the latest published versions of all dependencies

  Not a problem for Void, but in general I still agree that using crates.io whereever possible would be good, and same goes for using up-to-date dependencies. As long as they are compatible, we achieve the "up-to-date" bit with cargo-update, but it's better if it's updated upstream of course

• Remove nightly features

  This is probably the biggest hurdle for us too, Void also doesn't ship nightly, so we can't package Airshipper with nightly features.

---

Unrelated to those points: Airshipper only distributes builds for x86_64, built with glibc, right? Void Linux has a musl libc flavour, so having musl libc builds available would be nice, and the same goes for providing support for other architectures. Is that something that's even remotely planned?

[Songtronix]

iced released a new crates.io release which I will switch to for airshipper 0.5 which will only leave rocket to release on crates.io (as clap already released one but haven't switched yet)

With airshipper 0.5 I will switch to the stable channel as it's now possible with rocket.

Unrelated to those points: Airshipper only distributes builds for x86_64, built with glibc, right? Void Linux has a musl libc flavour, so having musl libc builds available would be nice, and the same goes for providing support for other architectures. Is that something that's even remotely planned?

Maybe. The server builds fine with musl but not sure about the client at all. This would require some investigations but surely would support all targets as long as they are maintainable (and you can actually play Veloren on).

[jcgruenhage]

Maybe. The server builds fine with musl but not sure about the client at all. This would require some investigations but surely would support all targets as long as they are maintainable (and you can actually play Veloren on).

Ah, sorry, I'll clarify: I meant the Veloren builds, that Airshipper distributes, not Airshipper itself. I'm asking because it would be kinda pointless to have an Airshipper package in Void for an aarch64-musl target, when you can't download a Veloren release for that target using Airshipper.

[Songtronix]

Flatpak builds for arm afaik and with the new macs we probably have to support them but I guess we will focus on the main ones (windows, linux, macos) without providing a lot of target variations (e.g. musl) as currently our CI time is already quite high.

[Frinksy]

I don't think that this should be something we require from application developers. Airshipper is one cargo workspace, with client and server being projects in that workspace. With the amount of projects using workspaces increasing (which has valid reasons IMO), I think we should work on our distro tooling/macros to support workspaces properly, instead of avoiding workspaces in projects

I actually agree with this. I'm still new to packaging software (airshipper is my first package), and now I think it is fine to keep it as a workspace: the rust2rpm tooling and packaging macros by default just grab the crate archive from crates.io. So if the airshipper client gets published to crates.io, packaging it should require very minimal effort (provided all the dependencies are already packaged, but that's another problem).

[KaratekHD]

With airshipper 0.5 I will switch to the stable channel as it's now possible with rocket.

Its great to see that this is planned, as we on openSUSE have similar problems as @Frinksy