https://bugzilla.redhat.com/show_bug.cgi?id=1403417 --- Comment #24 from Michael Schwendt <bugs.michael@xxxxxxx> --- > 3/ from the %files section > > %{_bindir}/* > %{_mandir}/man1/* > > > This is a no-no. This package simply cannot own all packages > under /usr/bin and /usr/share/man. As I've never before seen such a piece of advice, let me point out you're wrong here, because basically, this package MUST own all files under %_bindir and %_mandir/man1. The file ownership guidelines explain that. It can be a dangerous thing during package review to point out something that is not covered by the packaging/review guidelines. Well, you've tried to give a rationale, but that one is wrong/misleading. When we're building packages, we install into an _empty_ buildroot, and the %files sections include files found in that buildroot. Hence %{_bindir}/* %{_mandir}/man1/* is an entirely correct and acceptable way to include _all_ files this particular package installs below %_bindir and below %_mandir/man1. Using the '*' wildcard is a bit lazy, if there are only very few files to include or if all files use the same prefix, but it does the job. And it _cannot_ include any files in the package, which this particular package does not install into the empty buildroot. So, it has not been a mistake to do that. However, spelling out a bit the files to include can be beneficial, because then the %files sections serve as helpful file-existance checks, whereas a simple %_bindir/* wildcard would not ensure that /usr/bin/gsequencer exists in the package actually. Further, if you want to distribute files to multiple subpackages, using only '*' could lead to problems as you would need to explicitly %exclude files you want to include in other subpackages. -- 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx