https://bugzilla.redhat.com/show_bug.cgi?id=1403417



--- Comment #24 from Michael Schwendt <[email protected]> ---
> 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 -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to