Hi! I’d like to make mxcli easier to install on Arch Linux by publishing a community-maintained package in the AUR.
I understand that mxcli itself is licensed under Apache-2.0, so this is mainly a quick coordination check before I move forward.
My current idea is:
mxcli: build from a tagged source release using make build
- Possibly
mxcli-bin: install the prebuilt Linux binary from GitHub Releases
- Possibly
mxcli-git: track the latest source from the main branch
The package would contain only mxcli and the relevant license/documentation. It would not bundle MxBuild, Mendix Runtime, or other separately downloaded Mendix components. Those would continue to be downloaded only when the user explicitly runs commands such as mxcli setup mxbuild or mxcli docker run.
Before I start, could you let me know your thoughts on the following?
-
Do you have any plans to publish or maintain an official Arch Linux/AUR package?
If so, I’d be happy to avoid a naming conflict or help with the official package instead.
-
Do you have a preferred package name or release channel?
For example, should the main mxcli package follow tagged releases, or would you prefer a nightly or -git package while the project is still moving quickly?
-
Is make build the recommended build path for downstream packages?
From the current repository, it looks like the intended toolchain is approximately:
- Go 1.26.5, as specified by
go.mod
- ANTLR 4.13.2 for parser generation
CGO_ENABLED=0
Please let me know if there are any other build requirements or version constraints that downstream packagers should follow.
-
Are there any licensing or EULA notices you would like the package to show?
Again, I would not redistribute MxBuild or the Mendix Runtime. However, mxcli can download those components later when requested by the user, so I’d like to make sure the AUR package description or install notes mention anything that should be made clear.
-
Is there any preferred wording regarding the Mendix name or trademarks?
I plan to clearly describe it as an unofficial, community-maintained AUR package and would not use any logos or imply that the package is officially supported by Mendix.
-
Would you like to review the PKGBUILD before it is published?
I’d be happy to share it here first. I can also document the AUR package in the repository if that would be useful, although I’m also fine maintaining it entirely outside the upstream repository.
My goal is simply to provide a clean Arch Linux installation while keeping the package transparent, reproducible, and aligned with the upstream project.
Thanks!
Hi! I’d like to make mxcli easier to install on Arch Linux by publishing a community-maintained package in the AUR.
I understand that mxcli itself is licensed under Apache-2.0, so this is mainly a quick coordination check before I move forward.
My current idea is:
mxcli: build from a tagged source release usingmake buildmxcli-bin: install the prebuilt Linux binary from GitHub Releasesmxcli-git: track the latest source from the main branchThe package would contain only mxcli and the relevant license/documentation. It would not bundle MxBuild, Mendix Runtime, or other separately downloaded Mendix components. Those would continue to be downloaded only when the user explicitly runs commands such as
mxcli setup mxbuildormxcli docker run.Before I start, could you let me know your thoughts on the following?
Do you have any plans to publish or maintain an official Arch Linux/AUR package?
If so, I’d be happy to avoid a naming conflict or help with the official package instead.
Do you have a preferred package name or release channel?
For example, should the main
mxclipackage follow tagged releases, or would you prefer a nightly or-gitpackage while the project is still moving quickly?Is
make buildthe recommended build path for downstream packages?From the current repository, it looks like the intended toolchain is approximately:
go.modCGO_ENABLED=0Please let me know if there are any other build requirements or version constraints that downstream packagers should follow.
Are there any licensing or EULA notices you would like the package to show?
Again, I would not redistribute MxBuild or the Mendix Runtime. However, mxcli can download those components later when requested by the user, so I’d like to make sure the AUR package description or install notes mention anything that should be made clear.
Is there any preferred wording regarding the Mendix name or trademarks?
I plan to clearly describe it as an unofficial, community-maintained AUR package and would not use any logos or imply that the package is officially supported by Mendix.
Would you like to review the PKGBUILD before it is published?
I’d be happy to share it here first. I can also document the AUR package in the repository if that would be useful, although I’m also fine maintaining it entirely outside the upstream repository.
My goal is simply to provide a clean Arch Linux installation while keeping the package transparent, reproducible, and aligned with the upstream project.
Thanks!