https://bugzilla.redhat.com/show_bug.cgi?id=2085444 Cestmir Kalina <ckalina@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ckalina@xxxxxxxxxx --- Comment #18 from Cestmir Kalina <ckalina@xxxxxxxxxx> --- (Quoting Daniel Berrangé from comment #1) > Is rather unpleasantly obscuring what is actually being packaged. With > this kind of magic it is way too easy to accidentally ship undesirable files > in the final RPM. > > IMHO the %file section should be listing stuff explicitly, with few > wildcards, to make it clear what is being shipped. ie it is reasonable to > wildcard header files *.h, but not wildcard the nested trees. Please address this. (Quoting Daniel Berrangé from comment #12) > /usr/share is for architecture independent files, so that looks inappropriate for the SDK with many native binaries. What's your rationale for duplicating, for example, bin or include within /usr/share/sgx-sdk/? For example, what's stopping these from being in %{_bindir}? /usr/share/sgx-sdk/bin/x64/sgx_sign /usr/share/sgx-sdk/bin/x64/sgx_protoc /usr/share/sgx-sdk/bin/x64/sgx_edger8r /usr/share/sgx-sdk/bin/x64/sgx_config_cpusvn /usr/share/sgx-sdk/bin/x64/sgx_encrypt (Quoting Daniel Berrangé from comment #12) > Looking at what's in the RPM currently I'd think [...] /opt/intel/sgxsdk/include would be %{_includedir}/sgx-sdk. It's still in %{_datadir}/sgx-sdk/include. Is there any reason it can't be moved to %{_includedir}/sgx-sdk? (Quoting Daniel Berrangé from comment #12) >I'm still unclear what criteria was used to choose between /opt/intel/sgx-sdk/lib and /usr/lib64 in the current RPM, but assuming there's a reason that some libs needed to be in a different dir, then /opt/intel/sgxsdk/lib likely matches to a subdir like %{_libdir}/sgx-sdk (or possibly even %{_prefix}/lib/sgx-sdk, since multilib may well be irrelevant in the context of the SDK libs). It's still in %{_datadir}/sgx-sdk/lib64. Is there any reason it can't be moved to %{_libdir}/sgx-sdk or %{_prefix}/lib/sgx-sdk? (In reply to Yunying Sun from comment #15) > 1. "BuildRequires: perl" is not changed, since using "perl-base" instead > leads to various build errors complaining not able to find many other perl > libs like perl-FindBin/perl-lib(for lib.pm). As stated in Packaging Guidelines: Build-Time Dependencies (BuildRequires), a package must explicitly indicate its build dependencies (using BuildRequires:) outside of the minimal set required for RPM to build packages. This includes any dependency on Perl. While Perl may have been in the default buildroot at one time, this is not currently the case. Below is a list of Perl-related build dependencies you may need. perl-interpreter – The Perl interpreter must be listed as a build dependency if it is called in any way, either explicitly via perl or %__perl, or as part of your package’s build system. perl-devel - Provides Perl header files. If building architecture-specific code which links to libperl.so library (e.g. an XS Perl module), you must include BuildRequires: perl-devel. If a specific Perl module is required at build time, use +perl(+`+MODULE++)+`. This applies to so called core modules as well, since they may move in and out of the base Perl package over time. If you need to limit your package to a specific Perl version, use perl(:VERSION) dependency with desired version constraint (e.g. perl(:VERSION) >= 5.22). Do not use a comparison against the version of the perl package because it includes an epoch number, which makes version comparisons tricky. (In reply to Yunying Sun from comment #15) > 3. After using "BuildRequires: python3-devel" instead of "python", compiling > fails for can't find "python". New "BuildRequires: > python-unversioned-command" is added to fix the failure. You shouldn't depend on python-unversioned-command. Please look into %py3_shebang_fix. -- 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 https://bugzilla.redhat.com/show_bug.cgi?id=2085444 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
