https://bugzilla.redhat.com/show_bug.cgi?id=1760617
--- Comment #10 from Qianqian Fang <fangqq(a)gmail.com> ---
@Ankur
thanks for the feedback, my updated spec file and srpm file are updated in the
above post
here are my replies to some of the top issues you spotted, let me know what you
think.
-------------------------------------------------------------------------
Should the main spec/package be simply called mmc and then octave-..
as
sub-packages instead of the other way round?
done, the main package is now mmc, and octave-mmclab etc are now subpkgs
-------------------------------------------------------------------------
This confirms that the generated srpm does not match the latest spec.
Please
post the newest ones.
sorry, I must have forgotten to update the srpm previously. Now, the new srpm
can be found int he above post.
-------------------------------------------------------------------------
Please remove the executable perm
all the permission and end-of-line issues are now corrected in the upstream,
and I made a new upstream package to create the rpms
https://github.com/fangq/mmc/commit/2139721339907362f269562540b2d63ef88f0561
I confirm that these issues are fixed in the new srpm
-------------------------------------------------------------------------
Lots of bundling here too. Is this required?
this case is not bundling - the licenses found by the licensecheck are in the
source-code files. They are all compatible with the final binary's license
(GPLv3+) according to
https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses
as required by GPL license, once all these source units are compiled and linked
into a binary, the final generated software shall be licensed under GPL
https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
so, as long as the licenses of the source units are compatible with GPL, we
should label the final executable/package as GPL. So I believe what I did here
is correct.
-------------------------------------------------------------------------
here are some of the minor comments:
Why does the build require vim-common?
I use the xxd utility from vim-common to convert the OpenCL kernel file *.cl to
.h file in order to compile it in the binary; this is similar to the case in
mcxlab (Bug 1758622).
-------------------------------------------------------------------------
Please move the docs to the a sub-package.
I've already put all mmc/examples into mmc-demos and mmc/mmclab/example to
mmclab-demos.
-------------------------------------------------------------------------
- Build flags aren't used. Example from the build.log file:
Please use %{set_opt_flags} before you run %make_build
done
-------------------------------------------------------------------------
You do not need to use pushd, you can use %make_build -C
<directory name>
done
-------------------------------------------------------------------------
There's still the ln -s mex etc. Is this the latest srpm? (Each
time you
update the spec file, you need to regenerate the srpm and upload the latest
versions of both.)
I believe this was a result of obsolete srpm files. please run it again with
the new srpm.
-------------------------------------------------------------------------
[!]: Fully versioned dependency in subpackages if applicable.
Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in mmclab-
demos , mmc , mmc-demos
Do the Requires be versioned?
I think it is fine.
this is the initial package, all the features in the demos are supported by
this version. In the future, if some demos requires newer versions, I will add
version in Requires.
-------------------------------------------------------------------------
--
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