unicode/precis was moved to secure/precis. See [1] and [2] Meaning that packages requiring golang(golang.org/x/text/secure/precis) would need this package to be updated. packages requiring golang(golang.org/x/text/unicode/precis) would need to have upstream updated. [1] https://github.com/golang/text/commit/2b0166c3d4caae7d9b27290da81e3c3c680088a2 [2] https://go-review.googlesource.com/#/c/19157/ Since this is not in golang core, how is this being tracked upstream, since the package does not have versions?
These days I lack reviewers and go package maintainers. So most of the packages are in a state of flux. To your question. As most of go projects refer to dependency commit and not its version, all the dependency updates are commit driven. So it is enough to provide particular commit. Which one are you interested in? 2b0166c3d4caae7d9b27290da81e3c3c680088a2 or newer?
(In reply to Jan Chaloupka from comment #1) > These days I lack reviewers and go package maintainers. So most of the > packages are in a state of flux. I see. the commit driven dependency might be a problem at some point, whenever two packages require different commits of a project. In this case, the action would be to update the upstream depending on the older commit, right? > To your question. As most of go projects refer to dependency commit and not > its version, all the dependency updates are commit driven. So it is enough > to provide particular commit. Which one are you interested in? > 2b0166c3d4caae7d9b27290da81e3c3c680088a2 or newer? I believe it is already in rawhide though, I am closing this now. Thank you!
> I see. the commit driven dependency might be a problem at some point, whenever > two packages require different commits of a project. In this case, the action > would be to update the upstream depending on the older commit, right? We already hit the problem from time to time. Yeah, either update the upstream dependency or try to patch the current one.