https://bugzilla.redhat.com/show_bug.cgi?id=1816301
--- Comment #50 from Benson Muite <benson_muite(a)emailplus.org> ---
> a) In the spec file, can you change
> Prefix: /usr/lib/openfoam
> to
> Prefix: %{_libdir}/openfoam
OK to leave as is?
With the %{_libdir} macro it would expand to /usr/lib64 on openSUSE (for example), since
their site CONFIG_SITE has %{_lib} as lib64 > for x86_64.
I'd prefer to have a fixed/known install location, and also reuse as much as of the
spec as possible for both targets.
Probably adding an if statement is preferable if the behavior on OpenSUSE
should differ. Otherwise an
exemption is needed:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_multilib_exem...
> b) Please also change
> Release: 240429%{?dist}
> to
> Release: 1%{?dist}
>
> This is used to indicate changes in the spec file, for example due to
> rebuilds or changes
> to other options when the sources are not changed. It is independent of the
> actual release version of the sources.
Interesting. On previous copr builds it seems to ignore the auto
increment entirely (but my memory might be foggy), which is why I
forced to have the build date there too.
I can revert back without problem. Interesting, the openSUSE builds
prefer "0" instead of "1" for their Release, which is where they
slap
in the special handling. Would "0%{?dist}" also work for Fedora, or
just "1%{?dist}" ?
Fedora starts at 1. This is incremented for very spec file change without a
corresponding source version change.
It is possible to use the %autorelease macro to manage this.
See
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
With the "1%{?dist}" (or "0%{?dist}") I guess
that the previously built versions (with the date as release stamp) will mask out the
revised one. I'll need to see how to fix that I guess.
Can bump the epoch if there are many people using the copr build. You could
also create a new copr repo, and delete both
copr repos once the package is accepted.
> c) In the files listing, please change
>
> %{prefix}/%{projectDir}/COPYING
> %{prefix}/%{projectDir}/README.md
> %{prefix}/%{projectDir}/ThirdParty/README
DONE
Thanks.
> d) Is there any way to get wmake to mostly use Fedora specific
build flags?
We have provision for passing in extra stuff via the
FOAM_EXTRA_CFLAGS FOAM_EXTRA_CXXFLAGS FOAM_EXTRA_LDFLAGS
environment variables. Just not entirely sure should then be in there
for the spec file...
Something like this?
#-----
%build
# Mimic set_build_flags macro, but with wmake names
%if 0%{?fedora}%{?rhel}
FOAM_EXTRA_CFLAGS="${FOAM_EXTRA_CFLAGS:-%{?build_cflags}}"
FOAM_EXTRA_CXXFLAGS="${FOAM_EXTRA_CXXFLAGS:-%{?build_cxxflags}}"
FOAM_EXTRA_LDFLAGS="${FOAM_EXTRA_LDFLAGS:-%{?build_ldflags}}"
export FOAM_EXTRA_CFLAGS FOAM_EXTRA_CXXFLAGS FOAM_EXTRA_LDFLAGS
%endif
This seems better.
e) Please name the latest release version openfoam without anything additional
see:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1816301
Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...