Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=225615 Jan Kratochvil <jan.kratochvil@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|limb@xxxxxxxxxxxx |jan.kratochvil@xxxxxxxxxx --- Comment #6 from Jan Kratochvil <jan.kratochvil@xxxxxxxxxx> 2008-09-11 14:14:55 EDT --- Created an attachment (id=316467) --> (https://bugzilla.redhat.com/attachment.cgi?id=316467) Proposed changes. Changes attached, scratch build at: http://koji.fedoraproject.org/koji/taskinfo?taskID=820452 (In reply to comment #1) > binutils.src:20: W: prereq-use /sbin/install-info > The use of PreReq is deprecated. In the majority of cases, a plain Requires > is enough and the right thing to do. Sometimes Requires(pre), Requires(post), > Requires(preun) and/or Requires(postun) can also be used instead of PreReq. Fixed: +Requires(post): /sbin/install-info +Requires(preun): /sbin/install-info > binutils.src:22: W: unversioned-explicit-obsoletes gnupro > The specfile contains an unversioned Obsoletes: token, which will match all > older, equal and newer versions of the obsoleted thing. This may cause update > problems, restrict future package/provides naming, and may match something it > was originally not inteded to match -- make the Obsoletes versioned if > possible. Fixed: +Obsoletes: gnupro <= 1117-1 > binutils.src:303: W: macro-in-%changelog _prefix Not fixed as it was already used with single or double % case-by-case appropriately. One should see during `rpm -q --changelog' - fix multilib conflict in /usr/include/bfd.h and not: - fix multilib conflict in %{_prefix}/include/bfd.h > binutils.src: W: %ifarch-applied-patch Patch4: binutils-2.18.50.0.3-ia64-lib64.p > A patch is applied inside an %ifarch block. Patches must be applied > on all architectures and may contain necessary configure and/or code > patch to be effective only on a given arch. > > Not a problem. Not fixed, source tree is already arch-dependent as I was told by Roland McGrath. > binutils.src: W: summary-ended-with-dot A GNU collection of binary utilities. > Summary ends with a dot. Fixed. > Why are the .a files not in a -static package? What would be the ramifications > of correcting this? libiberty.a should be in fact removed as it should not be used by anyone as packages using libiberty have it bundled and build it on their own. libbfd.a and libopcodes.a are not ABI compatible across versions so their shared (.so) counterparts are not intended for linking with 3rd party applications - they are provided only for the binaries from this rpm. 3rd party applications link bfd/opcodes statically. There is nothing left for a possible -static package. (In reply to comment #2) > I think it would be better to change the perl substitution > to a sed substitution. Not done, IMO the Perl regex syntax is more flexible and I find the sed syntax obsoleted nowadays. > the gzipping of info files will be done automatically, Fixed. > I suggest using > %defattr(-,root,root,-) instead of %defattr(-,root,root) Changed (default directory attr; not in the scratch build). > Why not use %configure and why use %makeinstall? Changed for %configure. There was a separate build directory before which I am not aware how to configure while using %configure. But as I find the separate build directory more as an inconvenience than advantage and the practical reasons for it (gasp) no longer exist I changed it for a unified build/source directory back again and so even using %configure. (In reply to comment #5) > binutils.src:157: W: configure-without-libdir-spec > A configure script is run without specifying the libdir. configure options > must be augmented with something like --libdir=%{_libdir} whenever the script > supports it. This is a rpmlint error, --libdir is there but rpmlint did not parse it right through the %if blocks. Thanks, if it is fine going to commit it. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review