Le mardi 21 mai 2019 à 10:43 +0200, Brian (bex) Exelbierd a écrit : > Hi, > > I have submitted the first of my dependency review requests here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1712280 > > Feedback is greatly appreciated so I can clean anything up on the > next > set of dependencies. > > I am working on the main application packaging for gocryptfs > (https://github.com/rfjakob/gocryptfs/) and have hit a few questions: > > 1. The upstream provides specific source tarballs for each version > here, https://github.com/rfjakob/gocryptfs/releases - I am planning > to > use these as opposed to the gomacros to determine a git tag to pull. > Is there a reason not to do this
The downside is that you will lose the ability to switch easily to a tag or commit shall you need in the future. So, that depends if your upstream is reactive or not. If your upstream always releases manually when you need it to, you don't need to use the source our macro computes > > 2. The upstream build script sets up some values to be included in > the > executables version string. I presume this helps with debugging. I > am told that the Go SIG would prefer to see the macros used for > building rather than the upstream build script. This is fine, except > I am not sure how to handle these values. Specifically, they are: > > GITVERSION=$(cat VERSION) I don't remember if the macro version in fedora already does this, but the one that will land in devel soonish will compute that kind of ldflag by default for all go packages https://pagure.io/go-rpm-macros/blob/master/f/rpm/lua/rpm/go.lua#_61 > GITVERSIONFUSE=$(rpm -q golang-github-hanwen-fuse-devel --queryformat > '%{version}') That really begs for https://github.com/rpm-software-management/rpm/issues/607 It's sad that eveyone is reinventing its own hack to implement something taht should be done by default by rpm. If you have the time, please explain rpm upstream why tracking this kind of info is useful. > BUILDDATE=$(date +%Y-%m-%d) Please don't do that, that breaks build reproducibility. Regards, -- Nicolas Mailhot _______________________________________________ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
