Of course I’ve got to hugo, but we immediately run into a difficult decision.
See, I’ve always been of the opinion that web server software should not live in a distro’s repos. WordPress, Drupal, any web app, it isn’t a good model. For your desktop, folks move slower and fix deep problems, and we rarely get security freakouts where folks are at risk.
Not true with web software! My services get updated constantly!
Plugins, themes, modules: add-ons are too much to track in distros, for two reasons:
- There are 40,000 WP plugins in the public repo, no distro (read: group of volunteers) wants to take that on (I’d imagine this extends to the current curators, too! ^_^)
- You don’t want the 20 extra pieces of your site to not be able to update, because your distro’s core package can’t roll up with them
Now Hugo is a different beast, but just as complicated, despite being a parsing system rather than a web app. One would think it doesn’t really matter which version one runs, but it gets complicated, because the project updates often, it is very actively developed. But that means we are adding and changing things all the time (though rarely breaking anything, it is the promise of <1.0.0 that things can break).
You can check 1567909 – hugo-0.54.0 is available to see how difficult it is to keep Hugo up-to-date in Fedora. There may be a place for me to help out there, since I’d like to be more active in Fedora, and the hugo package seems like fairly impacting, low-hanging fruit. 
But we’ll have to answer, what is the point of a package? Will folks be able to pin a version of Hugo they need? Is that sustainable for the package maintainers?
In the meantime, and because I generally run the latest version, I decided to install the COPR at daftaupe/hugo Copr.
[maiki@yuzu ~]$ hugo version
Hugo Static Site Generator v0.48 linux/amd64 BuildDate: 2018-08-29T09:43:22Z