Open mattkeenan opened 1 month ago
@folbricht i'll keep this issue open as i add further config changes for a better package.
to that end, what other files do you think we should include by default?
also, i run ubuntu, and have been using debian for a few decades, so i know how to make the deb packages reasonably compliant. but it's been a long long time since i've done active rpm packaging, so not only rusty but also plenty of changes no doubt. would you or anyone else on the team be able to sanity check our rpm packages?
i've also included windows and darwin (macos) in the build process by default.
also, do you want me to create a base doc file for using goreleaser? aka goreleaser.md file with a brief explanation on how to use for not only us, but also in case end users want to use goreleaser for their own local purposes?
Thanks for doing this. As for your questions:
We should probably include a reasonable systemd service file. Not so sure about sysV though. Is there anything still using those?
Man pages would be nice. We may be able to generate them for the main executable at least since it uses cobra.
It's likely best to include a simple default config to get things started. It could be as simple as a TCP/UDP listener forwarding to quad9 or something, perhaps even a fast quic resolver. If there's a good spot for the other examples, they could be included. Or just have a pointer in the default config to https://github.com/folbricht/routedns/blob/master/doc/configuration.md and https://github.com/folbricht/routedns/tree/master/cmd/routedns/example-config
It's been a long while since I last made an RPM myself, but I run Fedora so should be able to test something.
A goreleaser.md
file would be nice to have. Could put it in the doc/
dir and link to it from the main README.md
with the goreleaser.md
file; i'll whip up a quick cheat sheet, and you can use it as a starting point for local testing as well as publishing.
As to the rpms sure, if you could test them that would be great.
Given that some of these changes might possibly overwrite (depending on the user's distro / settings) previous local configuration that someone made by hand before installing the package would you prefer to test this on a separate branch before merging to main?
Sounds great. I don't think we need a separate branch for testing.
I have an initial configuration for goreleaser that I can contribute to make it easier to build binaries and packages. It is just a first version for the moment and doesn't include docs, systemd, sysv-init, etc files (which I can provider after the initial commits).
I'll create a PR for this issue as well.