When installing `hugo` package, it does not mark `go` as a required dependency or even a weak dependency. As a result, when you try to start the local server, this happens: > $ hugo server > Error: failed to download modules: binary with name "go" not found Installing `go` and its dependencies clears this up. So it would be nice if that package is marked as a dependency of some sort.
Thank you for the report. See https://bodhi.fedoraproject.org/updates/FEDORA-2022-d64b9a26a9.
You're welcome, and thank you for fixing it!
But the side effect is that now, installing hugo pull 700 M of deps. I use it for a CI and our container image size exploded.
Upon inspection, golang-bin pull gcc, gcc pull glibc-devel, make. golang-bin also pull go-srpm-macros that pull golang-src that pull redhat-rpm-config and so a ton of libs to build things. Hence the 3 fold increase of the size of image. Could the deps be moved to a weak deps or something be done to avoid bloating the image ?
(In reply to Michael S. from comment #3) > But the side effect is that now, installing hugo pull 700 M of deps. I use > it for a CI and our container image size exploded. I imagine you do not use "go serve" in your CI pipeline, right? So it seems you want partial functionality out of the package, and you are willing to accept that things like "go serve" will not work. What features of Hugo do you use in your CI pipeline? I wonder if we should make a "-server" subpackage that depends on Go. I am also considering your idea about a weak dependency. It is not yet clear to me what the best way ahead is. I don't really like the idea of the default package being incomplete, so perhaps the weak dependency is better. Would you be willing to work out a solution and propose it as a src.fedoraproject.org pull request?
> I imagine you do not use "go serve" in your CI pipeline, right? Yup, I just build the website, and deploy it (if needed). As a alternative to the weak dep, another solution could be having a hugo-bin that contains just the binary (and the license), and have it required by the main package. A user using "dnf install hugo" would have it work out of the box (this original bug report), and people wishing to optimize can use the stripped down package. I will propose it as a PR (as soon as I figure how things changed since last time I built a package like %autorelease, etc)
That sounds like a sensible solution to me!
So here is the proposal: https://src.fedoraproject.org/rpms/hugo/pull-request/13 I have made a scratch build, but it failed on PPC64 during the tests (and I consider that it is unrelated to my change). However, I am a bit rusty, so I hope I forgot nothing with %autorelease and the new changelog system.
FEDORA-2022-14acc88896 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-14acc88896
FEDORA-2022-14acc88896 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.