Please consider to separate rudder-agent-thin from the rudder-packages repo
Hi,I think the best route forward would be to break out the thin agent as something that is maintained like a normal distro package and not a rudder component.
This would mean
- A separate repo
- SPEC and Deb files
- A single version supported (if you check out 3.2.4 you can only build the 3.2.4 agent)
- upstreaming in distros since it would be a normal package without magic
- safely moving to distro openssl etc
- easier porting to newer OS releases and architectures
- easier to port to new OS
- public CI builds and tests of the agent
The full agent wouldn't need to go through this procedure since it is too specific to be upstreamed anywhere anyway
#2 Updated by Benoît PECCATTE over 2 years ago
Thank you for your suggestion.
upstreaming in distros since it would be a normal package without magic
We may never want this since it means we would not control our version support anymore. Ie if a distro ships an outdated version, we would have to support it even if we don't want to.
safely moving to distro openssl etc
This is already the case with the current package (it is easier in master).
easier porting to newer OS releases and architectures easier to port to new OS
I don't see how it would make it easier.
public CI builds and tests of the agent
#5 Updated by Jonathan CLARKE over 2 years ago
Florian Heigl wrote:
Please note that what's in master is not helping anyone who wants to use rudder since that'd require a stable version. :-)
But I'll do my next try based on master :-)
Right... but if we just rewrite the code in stable branches, and it breaks the next minor release, there's going to be worse complaints, trust me ;)
In short, what is in master today will be stable tomorrow. We have to start somewhere.
Taking a step back: thanks for this ticket. It is a great reminder that we need a simple entry point to build a lightweight, standard, using-OS-dependencies rudder-agent package, to make it much easier for people to explore, understand and test on new platforms. Benoit, you said you don't see how having a standard package makes this easier - the answer is simple, most folk using a "different" system (FreeBSD, slackware, whatever) know what a standard RPM spec file looks like and how to port it to their OS, so if we give them a standard RPM spec file, they have something to work with.
As Benoît said, though, I don't see why this would warrant an independant git repo. If we're leaning anywhere, it would be merging all our git repos into one big monorepo (I'm not saying that's about to happen, just that we're not keen on making even more repos). Florian, do you know of a reason, or a "usual habit" that makes it more standard/understandable/easy for there to be a single package in a single repo?