Description
Is your feature request related to a problem? Please describe.
At the moment is is not possible to build k3s as an RPM or DEB package. This means I have to use the curl installer to install k3s on my host system. For me this represents an inconvenience because I would like to manage my system(s) via RPM/DEB packages.
Describe the solution you'd like
A build process which would build k3s only from sources checked in before build time. This would enable any Linux distribution to ship k3s in their repositories which should increase the visibility in a great manner. Specific build chains like dapper should not be involved in that process.
Describe alternatives you've considered
I have tried my best to understand how the current build system works and it is not even possible to exchange docker with podman without further bash reconfiguration (symlinks etc.). I have tried to understand the necessity of this - imho - inflexible buildchain and I lack the understanding of the decision sadly. I have tried to research the reasons but I was not successful.
Having a consistent environment for building can be achieved in many ways, I don't see a reason why this has to be achieved with dapper and continuos internet access.
Additional context
You said you'd disable this "for now" and reevaluate this later in #2440. I hope that this reevaluation can be done now. Obviously #1535 would reopen which I would also take care of then.
I am willing to invest my time to maintain this solution in the long term if we can find an agreement on how it should look like according to my desired solution.
Having RPMs and DEBs is not that hard if we consider the following:
- The specific requirements, for example for runc or containerd, can be built as subpackages of k3s. The build process is already available in most distributions, meaning that a
git clone ...like done here is not required. - The Traefik Helmchart can easily be built in any environment if the sources are previously downloaded since there is no black magic involved for this part of the build.
- For the userspace tools like
iptableswhich are currently a part of the k3s-root repository one can easily again just branch the required version from the distribution of choice like the first bullet point already describes.
The effort of doing this should be relatively small since the packaging of all the vendored dependencies is already done, they just need to be taken at the desired point in time. If architected well this doesn't even mean dapper is discontinued but in the end it would be just one options/the preferred option to build k3s.
For me the strongest point for such a solution is that the trust in k3s should be much higher when it comes from the vendor of your OS instead of a third party. Because normally packages are maintained by your OS vendor it is easy to trust them. If I execute a script of a third party I normally would need to establish trust to such a party first.
Additionally if I have an RPM/DEB I have a defined version which is installed. This means I know that a specific version will install a set of files on my system to previously known locations. When I install k3s via the current curl method I don't know what, where and how k3s will install itself on my system.
Lastly if an RPM would be available, one could take advantage of things like the SUSE Manager/Uyuni Content lifecycle management which enables automated staging of the k3s RPMs. This means a company can have an automated rollout for their k3s package with the tools already present in an environment, instead of a custom tailored solution.
Example: One could have a staging cluster where a new k3s package (with a bugfix or new version) is deployed to. If that is successful the package would be promoted to the next environment where the likelihood of that failing is much less then if I would install this directly in an environment.
Backporting
- Needs backporting to older releases
Metadata
Metadata
Assignees
Type
Projects
Status