Tightening dependencies

[flyn-org]

I maintain the Hugo package for Fedora.

During the packaging process, I have come across a few things that I patch around. I wanted to bring these things to your attention in the hope that you might be able to address them upstream. Should our discussion suggest it, I am happy to create individual merge requests.

1. Hugo (up to 0.98.0) relies on github.com/clbanning/mxj/v2 v2.5.5. Fedora provides golang-github-clbanning-mxj 2.5.5 (note the lack of the "v2"), and Hugo seems to build just fine against this. Did what was once known as "v2" get merged into the master branch? Can Hugo drop the use of "v2" and simply use the primary release of this package?

2. Hugo has for some time relied on github.com/gohugoio/go-i18n/v2. The "about" text associated with this repository reads "This is a short-lived fork to fix a critical upstream issue, do not use." Is it possible that Hugo could transition back to the upstream version of this package? Have they fixed the "critical upstream issue".

[bep]

1. github.com/clbanning/mxj/v2 v2.5.5. <== this is how Go modules works. It's admittingly unfortunate in this scenario, but I don't see how Hugo can solve it (without changing away from using Go's build tools).
2. I haven't checked lately.

[flyn-org]

1. Okay, I started a discussion with my fellow packagers to determine if we can solve this with "provides" statements.
2. I added this: Fix artificial language matching nicksnyder/go-i18n#253 (comment).

[flyn-org]

@bep, is there any hope of progress here? As I mentioned in nicksnyder/go-i18n#253, I am hesitant to package the fork because it bears the warning "This is a short-lived fork to fix a critical upstream issue, do not use."