Official Arch Linux package about dist HOT 5 CLOSED

Hi @shibumi, welcome to the project! 👋 We would love to have an official arch package that is endorsed by the Caddy project (and members from the community, since it's a lot of work to take on at our current size).

Thank you for providing this summary and overview, it's very helpful for me and I'm sure for others who have no idea what is out there or how this works!

However an official caddy image in the official Arch Linux repositories would have the side effect, that some of these packages would maybe vanish or would be renamed to caddy-legacy-*.

That's great, let's go the official route.

To be clear, we're only interested in version 2 going forward. I suppose if people wanted to keep up a v1 package they could, but we prefer that version 2 be prioritized/default (e.g. if the name "caddy" can only be used by one or the other, we'd rather have that refer to the newest version).

1. Arch Linux is bleeding edge, therefore we would only ship the newest stable release of the newest version (this would be caddy2 as caddy1 is considered deprecated, is this correct?).

Correct, and we prefer this too, rather than shipping old versions of stuff like Debian does. (Sigh.)

2. Arch Linux would enable all caddy2 features. We always ship our packages with all features enabled. We do this with many other packages as well. Systemd is the best example.

Sounds good, but to be clear what we mean by "all features" -- we are referring to all features that are in the caddyserver/caddy repository here on GitHub, right? Because there could be countless third-party plugins that are not hosted or maintained by us. Obviously, it wouldn't make sense to bundle those in.

3. We would like to ship it without telemetry. This point is important for us, we care about users privacy. However we also have a few packages with telemetry enabled (vscode for example, although it's possible to disable telemetry via configuration).

Caddy telemetry is not a privacy violation or impediment, but at the moment v2 does not have telemetry anyway.

4. We prefer signed releases, either via signed git tag/commit or via signed tarball.

All our tags are signed; we also have a build server with a signing key that produces custom, signed distributions. Hopefully that helps.

5. We are working on reproducibility, so a go.mod and go.sum file is a must-have for a go project. We also prefer a simple go build -trimpath over hacky makefiles.

Perfect, we prefer this as well, and we're fully on the Go modules train.

6. We ship our binaries with most security options enabled. Therefore we compile go binaries with go-pie (a go version that supports position independend code) and custom ldflags: LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now". Nonetheless we can do make exceptions (use go instead of go-pie, but we expect the devs to work on fixing this).

I don't think I know enough about these things to have an opinion right now, but, sounds good?

Anyway, all this sounds reasonable so far!

Next steps:

1. I would create a PKGBUILD file (this is basically a bash script), that builds caddy in a systemd-nspawn container, then I would extract the resulting binary and would test it on my system. If everything is fine, I would release it in the official Arch Linux repositories.

Cool. What would the install steps for the average user be like? If possible, we'd like to use the vanilla name caddy instead of decorated names like caddy2 or caddy-official or stuff like that.

2. I would make a PR and add the PKGBUILD to this repository as an example. Keeping that PKGBUILD up to date here as well, could be tedious. Not sure if you expect this.

Is it possible to centralize/unify them? We'd like to have control over them, and a single source of truth if possible, to avoid confusion and reduce maintenance.

3. I would rename/delete some of the AUR packages (caddy2 would get deleted and the caddy v1 packages could get deleted by our "inactive project" rule, if you consider caddy v1 as deprecated and nobody should use it).

Caddy 1 will be deprecated as soon as v2 stable is released (v2.0.0 tag), yeah. Ideally if we can cut it down to just one caddy package at that point, at least for now, that would be great.

We have a Slack for developers and maintainers -- can I send you an invite? That way if you need some tight feedback loop, it can make things go faster to collaborate, and then we track progress/commits here on the public repos.

from dist.

To be clear, we're only interested in version 2 going forward. I suppose if people wanted to keep up a v1 package they could, but we prefer that version 2 be prioritized/default (e.g. if the name "caddy" can only be used by one or the other, we'd rather have that refer to the newest version).

This is doable. The official package in our official repositories would be called caddy and I would rename the v1 caddy packages in the user maintained AUR.

1. Arch Linux would enable all caddy2 features. We always ship our packages with all features enabled. We do this with many other packages as well. Systemd is the best example.

Sounds good, but to be clear what we mean by "all features" -- we are referring to all features that are in the caddyserver/caddy repository here on GitHub, right? Because there could be countless third-party plugins that are not hosted or maintained by us. Obviously, it wouldn't make sense to bundle those in.

How will those third-party plugins be bundled? Same like in caddy v1? So the only way to get those plugins would be to recompile caddy2 with a specific plugin? If yes, we would have a problem. We need to either decide to just package caddyserver/caddy and tell the users to recompile the server if they want a specific plugin or we need to package every plugin permutation with caddy (We don't want to end up with over 20 different caddy packages in our repositories). I think other distributions could face this problem as well. Would be cool if caddy would support both: one binary with plugins or just the caddy server with a plugin in a separate file. (I know that caddys focus lies on containers, and there one fat binary makes totally sense).

Caddy telemetry is not a privacy violation or impediment, but at the moment v2 does not have telemetry anyway.

This is good to hear. I can understand your wish for telemetry or your defensive position, but some users go wild if they just hear the word 'telemetry' :). I just want to avoid this.

All our tags are signed; we also have a build server with a signing key that produces custom, signed distributions. Hopefully that helps.

Nice.

Perfect, we prefer this as well, and we're fully on the Go modules train.

This is good to hear as well.

1. We ship our binaries with most security options enabled. Therefore we compile go binaries with go-pie (a go version that supports position independend code) and custom ldflags: LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now". Nonetheless we can do make exceptions (use go instead of go-pie, but we expect the devs to work on fixing this).

I don't think I know enough about these things to have an opinion right now, but, sounds good?

One short note about this: Most Go applications run without a problem with these hardening features. (no idea why the go devs don't enable those on default).

Cool. What would the install steps for the average user be like? If possible, we'd like to use the vanilla name caddy instead of decorated names like caddy2 or caddy-official or stuff like that.

Yep, I would use the name caddy in our official repositories. The unofficial caddy package in the user maintained AUR, would get renamed to caddy-legacy, because it refers to caddy v1 anyway.

Is it possible to centralize/unify them? We'd like to have control over them, and a single source of truth if possible, to avoid confusion and reduce maintenance.

Well, I could always open a PR with the specific PKGBUILD change on this repository, but this could get very noisy. The advantage would be that you would see transparently every change we make and you could guide the users to this PKGBUILD if they want to compile their own caddy version on Arch Linux. The first PR would involve a full PKGBUILD, the next PRs would be just a one line change (basically a version bump only aka changing the version number in a shell script).

We have a Slack for developers and maintainers -- can I send you an invite? That way if you need some tight feedback loop, it can make things go faster to collaborate, and then we track progress/commits here on the public repos.

Sure, send me an invite on Chris.rebischke @ archlinux.org

from dist.

Do we need to keep this open? What remains?

from dist.

I would like to keep this open until we have the package as stable version in the official repositories. Right now it's just a custom repository.

from dist.

Arch files are removed from here as per #58, and the official arch repo now exists, so this is done.

from dist.