https://bugzilla.redhat.com/show_bug.cgi?id=1816301
--- Comment #50 from Benson Muite <benson_mu...@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_exempt_locations
>> 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=report-spam&short_desc=Report%20of%20Bug%201816301%23c50
--
_______________________________________________
package-review mailing list -- package-review@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/package-review@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
