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