On Tue, May 21, 2019 at 4:53 PM Nicolas Mailhot <nicolas.mail...@laposte.net> wrote: > > 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
If the upstream changes release mechanisms I am happy to revisit the packaging. > > 2. The upstream build script sets up some values to be included in > > the > > executables version string. > > 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 As this has not landed, I need to move forward with this for now. Additionally, as we are pulling the value from a file and not calculating, I would prefer to see the upstream value retained just in case they choose to put additional details we don't calculate by default. > > GITVERSIONFUSE=$(rpm -q golang-github-hanwen-fuse-devel --queryformat > > '%{version}') > > That really begs for > https://github.com/rpm-software-management/rpm/issues/607 While this issue may have value, it seems to tackle a different problem. > > BUILDDATE=$(date +%Y-%m-%d) > > Please don't do that, that breaks build reproducibility. My understanding is that reproducible build systems typically provide a build date value. Looking through https://docs.fedoraproject.org/en-US/packaging-guidelines/ I don't see one for Fedora. Do you know what it is? thanks, bex _______________________________________________ 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
