New package: perl-MP3-Tag

[Chip Turner]

On 6/26/05, Ville Skyttä <ville.skytta at iki.fi> wrote:
> On Sat, 2005-06-25 at 20:08 -0700, Chip Turner wrote:
> 
> > brp-compress HAS to be called explicitly when you build a %files
> > section programmatically, otherwise rpm doesn't find the resulting
> > manpages.
> 
> The somewhat ugly thing about this is that explicitly
> invoking /usr/lib/rpm/brp-compress means overriding the system's
> rpmbuild configuration in a blindfolded way.
> 
> For example, when redhat-rpm-config is installed, the brp-compress to be
> used actually lives in /usr/lib/rpm/redhat/brp-compress,
> not /usr/lib/rpm/brp-compress.  Granted, there are currently no
> functional dependencies between the two.  But
> if /usr/lib/rpm/$vendor/brp-compress would eg. run bzip2 instead of gzip
> on the manpages (and the vanilla /usr/lib/rpm/brp-compress not, which
> would be a valid setup as such, assuming I understand correctly how
> rpm's system config is supposed to be extended), things would break.
> 
> Some improvement ideas:
> 
> 1) Don't invoke any brp-compress, but append "*" to the man pages in the
> generated files list.  This might still assume too much of the rpmbuild
> config internals.
> 
> 2) Don't invoke any brp-compress, exclude man pages from the generated
> files list, and add an explicit %{_mandir}/man*/*.* in the %files
> section.  Again, might assume too much.
> 
> 3) Use /usr/lib/rpm/%{_build_vendor}/brp-compress if it exists, falling
> back to /usr/lib/rpm/brp-compress if not.  And actually while at it,
> replace /usr with %{_prefix} in both of the above in any case.
> 
> I think 3) above would be the best one (of these ideas).  Your thoughts?

Good analysis, I totally agree; 3 is best.  I've implemented it to try
both, preferring the build_vendor one.  I think it's the most
practical and reliable of the three.

Thanks
Chip

-- 
Chip Turner                   chip.turner at gmail.com