Publish QMS releases for OS Windows via Windows Package Manager?

[JFritzle]

Some Linux distributions and/or third party repositories allow for the installation of QMS via their package manager, which simplifies the installation process for less experienced users.

What about publishing QMS releases for OS Windows via Windows Package Manager?
This could simplify QMS installation and in particular QMS update from command line, e.g.
by winget install qmapshack.qmapshack to install or
by winget upgrade qmapshack.qmapshack to update to latest provided release.

[wthaem]

Why not offering an additional distribution channel or even replacing the existing one. Please, comment on the legal issues to follow when using the package manager. Are there any volonteers to deal with this topic?

[JFritzle]

Legal issues are described here.

We will have to create a product's manifest using an existing manifest creation tool.
Manifest is more or less the only data submitted to Windows Package Manager Community Repository. The installer's download URL is contained in manifest and points e.g. to QMapShack's github repo or, if you @wthaem provide the installer, to your github repo. I would prefer QMapShack's github repo. Couldn't we not better provide binary releases to be downloaded in QMapShack's github repo instead of only providing a link to a maintainer's own github repo?

We have to define a package identifier for our product, e.g.

• Maproom.QMapShack if we want to have the chance to distinguish with additional products Maproom.QMapTool
• QMapShack.QMapShack if we never want to publish more than one product's installer

See Garmin's Basecamp manifests as template.

[kiozen]

I would like to keep the binaries out of the source repository. This is based on the concept of Linux and Opensource. Software projects provide code. Distributions provide binaries. This has some benefits.

By forking the main repo the binary maintainer has the possibility to version code that is specific to his/her build environment. The main build scripts and instructions are handled by the main repo. But I am sure they do not fit everyone's liking.

With the own repo it's also possible to create your own release. Either because you need to fix an OS specific issue right after the official release or because you want to have a feature in the binary without an official release. In any case the maintainer has all options and does not have to interfere with the main repo.

Responsibilities are assigned in a very clear and verbose way. The maintainer's repository has it's own ticket system. If there is an issue with the binary it can be resolved in the maintainer's repository. If there are legal issues (I hope there never are legal issues) they are limited to the repository with the binary.

Let me give an example: Maintainer X decides to bundle a proprietary library with QMapShack. If this causes problems, the problems stay within the maintainer's responsibility. If the binary is part of the main repo, it's the problem of the main repo.

Same applies to unintentionally (or evil: intentionally) distributed malware. Taking over binaries in the main repo would need a lot of trust and intense checking of the binary. Let me point it out very clear: Currently I trust all maintainers of binary packages that are linked on the release page on a 100% level. So the evil case is not an issue. But no one is immune to infected build systems when it comes to binaries.

In the past I had one attempt to sneak in advertising. Personally that is ok for me, but not as an official binary package provided by the main repo under my name.

And by having the binary in his/her own repository the maintainer has full control of his/her work. If the maintainer wants to remove the binary from the net he/she can do without asking anyone else.

That is why I really think the "fork the repo and provide binaries in your own fork" is the best approach.