https://bugzilla.redhat.com/show_bug.cgi?id=2085444 --- Comment #4 from Daniel Berrangé <berrange@xxxxxxxxxx> --- (In reply to xiangquan.liu from comment #2) > (In reply to Daniel Berrangé from comment #1) > > * The section > > > > find %{?buildroot}/license -type f -print0 | \ > > xargs -0 -n1 cat >> %{?buildroot}%{_docdir}/%{name}/COPYING > > rm -fr %{?buildroot}/license > > echo "%{_install_path}" > %{_specdir}/listfile > > find %{?buildroot} -type d -exec \ > > sh -c '(ls -p "{}"|grep />/dev/null)||echo "{}"' \; | \ > > sed -e "s#^%{?buildroot}##" | \ > > grep -v "^%{_libdir}" | \ > > grep -v "^%{_bindir}" | \ > > grep -v "^%{_install_path}" | \ > > sed -e "s#^#%dir #" >> %{_specdir}/listfile > > find %{?buildroot} -type f | \ > > sed -e "s#^%{?buildroot}##" | \ > > grep -v "^%{_install_path}" >> %{_specdir}/listfile > > > > %files -f %{_specdir}/listfile > > > > 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. > > > > As a case in point, this current magic obscures the fact that the majority > > of files in this RPM has been put into /opt/intel/sgxsdk. Fedora RPMs are > > not expected to use /opt except in rare cases > > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > #_limited_usage_of_opt_etcopt_and_varopt > > > > so if there's a good reason for use of /opt it needs a justification to be > > provided > > [Xiangquan] I would like to explain the reason why using lines of scripts > here. We want to share some scripts/files between rpm and debian. In this > case, we just need to update one place for both rpm and debian. For example, > if one file is added or deleted, only BOM file is updated. If it is not > acceptable, it will be updated. If an official Debian package is ever to be added to the main Debian package repos, it shouldn't use /opt either per their lint guidelines https://lintian.debian.org/tags/dir-or-file-in-opt In any case, other packaging choices made for distros are not a suitable justification to diverge from Fedora packaging guidelines excluding use of /opt > > * The package possibly ought to have a -devel sub-RPM for the include files > > & .pc files, so they're separate from the runtime .so files > > > > [Xiangquan] Actually SGXSDK is package just for developers. That's true of lots of packages, but generally if there's a packaging shipping ELF libraries, normal practice is for the header/pkg-config files which are needed ONLY at compile time, to be separated from the ELF files which are needed at compile and execution time. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages There can be exceptions, for example the above page notes "compilers often include development files in the main package because compilers are themselves only used for software development, thus, a split package model does not make any sense." but AFAICT, this sgx-sdk package doesn't contain compilers/toolchains, just a bunch of libraries & headers -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
