Overview
Request 1153513 superseded
- Use standard source-download feature, modified _service file and removed _servicedata
- Don't use pie-buildmode for ppc64 and s390x architectures
- configuration changes:
* Enhanced default configuration file, including configs for http3 support.
* Docker configuration has been disabled per default, file provider has been enabled
* Prepared directories for logging and for dynamic configuration
- frontend packaging:
* Changed packaging of webui: Invoke `prepare-sources.sh` to creaet a package
of node_modules used to build the webui during packaging.
* The frontend will now be packaged on OBS. The negative side-effect is, that
the package can not be built on the ppc64le platform as well as for Leap 15.5 and 15.4,
because some packages are not available there.
- Go packaging:
* Added upstream patch traefik-fix-int-overflow-with-go-generate-10452.patch to
allow packaging on 32bit architectures gh#traefik/traefik#10451
* Enabled CGO because there is no cross compilation needed in OSB (we build
packages for every distribution/architecture seperately). PIE can not be used
with CGO enabled for most architectures and is reported as failure sinc go 1.22.
See https://github.com/golang/go/issues/64875
- Update to version 2.11.0:
- Created by weberho
- In state superseded
-
Package maintainers:
avicenzi,
pgeorgiadis, and
weberho
- Supersedes 1151460
- Superseded by 1155081
I have added the packaging of the front-end into the spec file. Works nicely, but isn't supported by Leap. Therefore it could be easier to leave the packaging of the front-end for the packager. The "new" way is recommended, but I'm not sure if it's the best.
The node packaging is nice, but I believe that we should stop using git-scm and instead fetch the released tarball. The tarball will include the compiled html/css, reducing the work required on the package side. This will also work on all architecture and versions.
PIE does not work on PPC, we can disable PIE on PPC, if RISC-V is also an issue, I would disable it there as well.
HTTP3 is experimental, I would leave it disabled by default, but not a major issue.
I would not redirect all traffic to HTTPS, there's no certificate, a self-signed one will be used.
The config should be the bare minimum for the service to start, like NGINX, but the users still need to setup their preferences.
Thanks, @avicenzi for reviewing! I'll prepare a new package. I'll soon submit a new package and will add a longer comment there.
Request History
weberho created request
- Use standard source-download feature, modified _service file and removed _servicedata
- Don't use pie-buildmode for ppc64 and s390x architectures
- configuration changes:
* Enhanced default configuration file, including configs for http3 support.
* Docker configuration has been disabled per default, file provider has been enabled
* Prepared directories for logging and for dynamic configuration
- frontend packaging:
* Changed packaging of webui: Invoke `prepare-sources.sh` to creaet a package
of node_modules used to build the webui during packaging.
* The frontend will now be packaged on OBS. The negative side-effect is, that
the package can not be built on the ppc64le platform as well as for Leap 15.5 and 15.4,
because some packages are not available there.
- Go packaging:
* Added upstream patch traefik-fix-int-overflow-with-go-generate-10452.patch to
allow packaging on 32bit architectures gh#traefik/traefik#10451
* Enabled CGO because there is no cross compilation needed in OSB (we build
packages for every distribution/architecture seperately). PIE can not be used
with CGO enabled for most architectures and is reported as failure sinc go 1.22.
See https://github.com/golang/go/issues/64875
- Update to version 2.11.0:
Thanks, @avicenzi for reviewing!
All those configurations you mentioned in your last comment are disabled, so that the config stays the same as before. There is one exception: I have per default disabled the docker-provider and enabled the file-provider. It seems to me more reasonable to use a file-provider when installing the package with that rpm.
Regarding the tarball, there are two available: The classical compressed source and a kind of pre-packaged one (the first and the last in the list). I have now switched to the source only which builds nicely but not in the Leap distribution. The advantage is, that the full build-process is reproduce-able.
I personally would prefer a .yml file for the configuration, as I hardly understand the .toml file. But as it's not my project, I'll not change that :-)
Everything looks good, but I would clean up the .changes file. A few things were included in the previous SR, but not removed, and they were not merged (just superseded), so it makes no sense to mention them.
Yaml vs Toml is a good point, I also prefer Yaml, but Traefik used to document everything in Toml, which is why it was selected. While we have a no-replace for config files, the systemd service has the config file location. Changing the format changes the file name and this would break the no-replace config, unless there's a smarter way to not break previous installations I would not change it now.
We can, of course, consider replacing Toml with Yaml once we have Traefik 3.0, this is very likely to require some migration path as seen in 1.7 to 2.0.
If you don't mind, I can accept and clean up the .changes file myself before sending it to Factory.
Yea, please do so - thanks for the input, I fully agree to everything!
@avicenzi, @pgeorgiadis: review reminder