Releases?

[LDprg]

How are we doing on release, because most distro package manager require them.

There are view things we should think about:

• Release Versioning (0.1 or 0.0.1 or sth. else)
• Release Management, are we going to use the default GitHub releases or do we create a release branch
• How are we dealing with the rewrite and legacy packages so there is no collision (design them to work in parallel or only allow one or the other)
• Distribution, which package managers and how their requirements are
• For the rewrite we should consider uploading the code to crates.io, which would allow installation via cargo

[LDprg]

As I am using Arch (btw) I would take care about the AUR package. As it is easier to get a package there than in the pacman repos.

[oskardotglobal]

For the versioning I'd go with good old semantic versioning: https://semver.org/

Github releases would also be a good idea. We could just start by distributing binaries as tarballs via github releases and then go from there. As for deb-based and rpm-based distros (I personally use fedora), downloads with the deb and the rpm will suffice (On fedora you can directly install software via a link to the rpm using dnf)

Also, for the collision problem I'd just name legacy "winapps" and then rewrite would be "winapps2"
And at some point we'd just abandon winapps2 and upload the rewrite artifactes under "winapps"

[LDprg]

It is probaply the best to distribute deb and rpm for now. Maybe we could consider the Debian community repository and rpm fusion for later.

[LDprg]

What if we use winapps-legacy and winapps or the other way around winapps and winapps-rust or something like that for naming.

This would probably cause less confusion.

[AkechiShiro]

I would go for your choice @LDprg but most likely not renaming the old binary as winapps-legacy but leaving it as is for (old users/not creating confusion for old users/conflicts in pkg managers), and I would go for :

• Legacy : winapps
• New : winapps-rs (shorter than winapps-rust)
• New proposal 2 : winapps-ng

[LDprg]

Also how about AppImages or Flatpacks for non Debian Fedora Arch based distros?

[freechelmi]

Flatpak is a great way to target all users at once , even chromeOS users.

I'm not experience in flatpak but I can have a look as I was willing to learn it anyway

[bayazidbh]

AUR, someone will probably make them. I think it's best to just allow the AUR community to make and maintain the PKGBUILD, and only monitor and give advice only when there's an issue. Unless someone in the new winapps teams wants to maintain it themselves?

Deb and RPM would be great. Maybe use OBS to build the binary then?

[fbartels]

In the past we had an obs installation at work to create packages through it. even when using their public instance I don't think its worth the effort for a single package. Better to use a github action to create these.

[bayazidbh]

Fair enough. Should probably have an update-check mechanism then - one advantage of OBS I recall was that you can add them as repo on both Debian and Ubuntu (depending on how it's setup) which is nice for updating.

[PaulCombal]

As an Ubuntu user, Snap and Flatpak make the most sense. Debian packages would typically be used for system dependencies only. Correct me if I'm wrong.

[oskardotglobal]

What about nix? We could also use that, quickemu uses it.

[LDprg]

Seems perfect for winapps and nix package manager seems quite common for distribution.

[bayazidbh]

Nix will be tough, I don't recommend it to start with. You'll need to learn a lot about how Nix works, and have to pass a pretty strict test to ensure it is reliable and reproducible.

The Nix userbase is growing (even SteamOS including an offload for /nix now in Main branch) but Flatpak is still the much more popular solution due to its simplicity with PackageKit allowing for easy GUI installation.

[oskardotglobal]

I know someone who might be able to help with that

[AkechiShiro]

@bayazidbh I'm maintaining currently 2 pkgs in Nixpkgs in Nix, Azure-cli and Bloodhound, I'm still a newbie at writing a NixOS module but I believe we can find a way to move forward using Nix.
Quickemu is already packaged in Nix as well : https://github.com/NixOS/nixpkgs/blob/nixos-23.05/pkgs/development/quickemu/default.nix#L93

Hence giving us a immense headstart, we'll depend on it, from what I've read so far.

[AkechiShiro]

Also this could help us in packaging Rust with Nix : https://www.youtube.com/watch?v=HGIKY2XpCFU
I was at Nixcon 2022, and I met the author of this talk.