Add build constraint to allow compiling without cgo

[alfrunes]

The PKCS11 feature (not used by the backend) prevents compiling mender-artifact without enabling cgo.

[mender-test-bot]

@alfrunes, Let me know if you want to start the integration pipeline by mentioning me and the command "start pipeline".

---

my commands and options

You can trigger a pipeline on multiple prs with:

• mentioning me and start pipeline --pr mender/127 --pr mender-connect/255

You can start a fast pipeline, disabling full integration tests with:

• mentioning me and start pipeline --fast

You can trigger GitHub->GitLab branch sync with:

• mentioning me and sync

You can cherry pick to a given branch or branches with:

• mentioning me and:

 cherry-pick to:
 * 1.0.x
 * 2.0.x

[ghost]

I think this should be made into a feature flag (such as nopkcs11 or something like that). I think silently disabling features if cgo is disabled is surprising and unintuitive.

However, independent from that, I don't think it will work as intended, because I think lzma requires cgo as well, and we can't disable that. Not 100% sure though.

[alfrunes]

I think this should be made into a feature flag (such as nopkcs11 or something like that). I think silently disabling features if cgo is disabled is surprising and unintuitive.

This is exactly how we do it for lzma (I found out after filing this PR), and I agree that disabling features should be explicit. However, this feature abuse the built-in linux constraint which makes impossible to opt out (in the backend we do not use this dependency). I will change the build tag to pkcs11 and have it set by default in the Makefile.

However, independent from that, I don't think it will work as intended, because I think lzma requires cgo as well, and we can't disable that. Not 100% sure though.

For lzma I will similarly add a different (Go) dependency if compiled without cgo since this one is crucial.

[alfrunes]

Thoughts on this one? #605

[lluiscampos]

Please keep the version aligned to yocto, see comment above.

Coincidentally, we are discussing this in the upcoming client team meeting.

[alfrunes]

Please keep in mind that go1.17 has been out of support for almost 2 years. Is it not possible to use the most recent version of Go when compiling Yocto?

[lluiscampos]

Yocto maintains the toolchain, porting security fixes (same as for example Debian or other OSs do for the same time period that they support the OS).

Fixing the version here does have any impact in the final yocto build nor in the deb packages build.

Fixing the version here is only a way for us (me) to early catch when updates will break in today latest yocto LTS. Then we can decide to accept the breakage and patch the code there or reject the update for the time being. It is a difficult balance - to give you a small picture: we still support dunfell LTS which uses golang 1.14 and it is really hard and time consuming delivering our software there.

[alfrunes]

Superseded by #605