[Bug 225615] Merge Review: binutils

bugzilla at redhat.com bugzilla at redhat.com
Thu Sep 11 18:14:58 UTC 2008


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 at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|limb at jcomserv.net           |jan.kratochvil at redhat.com




--- Comment #6 from Jan Kratochvil <jan.kratochvil at redhat.com>  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.




More information about the Fedora-package-review mailing list