[Bug 1135654] Review Request: libpuma - Library for parsing and manipulating C/C++ source code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



--- Comment #3 from Michael Schwendt <bugs.michael@xxxxxxx> ---
> %package doc
> Summary:        Documentation for %{name}
> Requires:       %{name}%{?_isa} = %{version}-%{release}
> BuildArch:      noarch

It is not just inconvenient to hardcode such a dependency in a Documentation
package, so the package cannot be installed without pulling in lots of
dependencies. Please keep doc packages free of such deps unless the base app is
strictly required to display the doc files.

A "noarch" subpackage _cannot_ depend on %{?_isa}, because it may be built on
any arch and is put into all repos for different archs.


> Name:           libpuma
> # The generated config depends on a specific version of gcc/g++
> Requires:       gcc-c++ = %{gccver}

Here %{?_isa} would make sense. The generated .config file (_not_ in libpuma
package btw) seems arch-specific, subpackage "-aspectc++" (which is not
multi-lib) requires arch-specific libpuma, so libpuma ought to require the
arch-specific compiler, too.


> # Fix the FSF's address
> for f in $(grep -FRl 'Temple Place' .); do
> ...
>   touch -r $f.orig $f
> ...

Nasty trap. ;)

Seeing this I wondered about the license file, and indeed you modify the
license file which must not be done:

  https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/package-review





[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]