https://bugzilla.redhat.com/show_bug.cgi?id=1727502
--- Comment #2 from Jerry James <loganjerry(a)gmail.com> ---
(In reply to Jakub Jelen from comment #1)
I think the date in the release should be the date when you pulled
the
tarball from upstream, not the date when the tarball was created by upstream
(especially if I see newer changes in the git
https://gitlab.com/janezkonc/mcqd/ ). But that is not very important since
this detail is not explicitly clarified in the packaging guidelines.
Hmmm, that's an interesting point of view. I've always thought of those dates
as giving information about the last time upstream did something to the code,
hence the date of the commit. You're right though; the guidelines just say
"the date" without specifying *which* date, leaving that open for
interpretation.
I see you only packaged only the binary file which is kind of
example
program. I am wondering whether it would make sense to package also the
header files in the -devel subpackage, if you plan to use that algorithm in
some of your work/packages/tools.
Yes, you are absolutely right. I have made that change.
You should use "install" instead of "cp" and
"mkdir".
Why do you think so? I've always found install kind of clunky to use, so I
prefer to use cp. Plus install cannot copy symbolic links, just what they
point to; cp does not have that limitation.
I do not see the mcqd binary to produce exit code if it fails (but I
am not
a C++ programmer so I might be missing something). So I think for the check
to be useful, you should check that the produced output is sane, for example
the output contains "Maximum clique:" twice or something like that.
Yes, you are correct. I have attempted to check this.
Thanks for the careful review! New URLs:
Spec URL:
https://jjames.fedorapeople.org/mcqd/mcqd.spec
SRPM URL:
https://jjames.fedorapeople.org/mcqd/mcqd-1.0.0-1.20160901.9ab9717.fc31.s...
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component