This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 454408 - (mingw32-binutils) Review Request: mingw32-binutils - MinGW Windows binutils
Review Request: mingw32-binutils - MinGW Windows binutils
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On: mingw32-filesystem
Blocks: mingw32-gcc mingw32-runtime mingw32-w32api mingw32-zlib mingw32-opensc mingw-log4c
  Show dependency treegraph
 
Reported: 2008-07-08 07:13 EDT by Richard W.M. Jones
Modified: 2013-10-07 15:04 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-09 12:00:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
rc040203: fedora‑review+
dennis: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2008-07-08 07:13:37 EDT
Spec URL: http://www.annexia.org/tmp/mingw/mingw-binutils.spec
SRPM URL: http://www.annexia.org/tmp/mingw/mingw-binutils-2.18.50_20080109_2-5.fc10.src.rpm
Description: MinGW Windows binutils

Incomplete packaging guidelines:
https://fedoraproject.org/wiki/PackagingDrafts/MinGW

This is 'binutils' for the MinGW Windows cross-compiler.  This
particular package is just a straightforward compilation of
the binutils upstream source, with the host set to i686-pc-mingw32.
Comment 1 Ralf Corsepius 2008-07-08 09:09:53 EDT
(In reply to comment #0)
> ... the host set to i686-pc-mingw32.
You mean --target :)

Clean package, nothing much to say about it.

APPROVED.

Comment 2 Daniel Berrange 2008-07-08 09:44:06 EDT
Not so fast with approving this.

IMHO, having separate mingw SPEC files is totally unsustainable for
maintainence. We need to build from the existing binutils SPEC file, perhaps
just adding a sub-RPM with the mingw build of it (cf kernel SPEC which builds
many sub-RPMs with different variants, PAE, SMP, UP, etc)
Comment 3 Ralf Corsepius 2008-07-08 09:58:24 EDT
(In reply to comment #2)
> Not so fast with approving this.
Well, I am packaging cross-toolchains for > 10 years (comprising mingw, cygwin
and many others.). So I am familiar with many issues packagers typically trip over.
 
> IMHO, having separate mingw SPEC files is totally unsustainable for
> maintainence.
I disagree. From my experience, anything but using a separate spec file,
separate tarballs and separate patches is non-maintainable.

> We need to build from the existing binutils SPEC file,
Why? MinGW is not Linux, uses different sources, has a different upstream,
suffers from different bugs, etc.

> perhaps
> just adding a sub-RPM with the mingw build of it (cf kernel SPEC which builds
> many sub-RPMs with different variants, PAE, SMP, UP, etc)
MinGW is not a variant of Linux. 

MinGW is a different OS with an independent upstream, with different libraries,
different GCC and many other differences.


Comment 4 Richard W.M. Jones 2008-07-08 10:33:49 EDT
Ralf is correct here, and I was confused.  This package doesn't
contain binutils as I said above, but a version of binutils which
is heavily patched (forked, basically) by mingw upstream.

Thus, having a single binutils SPEC file which builds a mingw
subpackage isn't going to work too well, since mingw's binutils
is forked and released on a different schedule from binutils.
Comment 5 Daniel Berrange 2008-07-08 14:03:54 EDT
After further discussion on fedora-devel it seems we have no choice but to
maintain a custom forked RPM, since upstream binutils for MinGW doesn't supply
clean patches for binutils releases :-(

I would suggest that we use the name 'binutils-mingw' instead of
'mingw-binutils' as the RPM name though, since other mingw packages will likely
be done as sub-RPMs with a -mingw postfix to their name
Comment 6 Richard W.M. Jones 2008-07-10 06:15:29 EDT
Can we move this package further along now?  (As in, is there anything
left to be discussed?)

On the naming issue, I prefer mingw-binutils, and other packages can be
built with the consistent naming even if they are built as subpackages
(as an example, see my proposal for a GnuTLS subpackage here:
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00435.html )

The reason I prefer mingw-* is that it keeps all the related packages
together in rpm, yum and Bugzilla's list of components.
Comment 8 Richard W.M. Jones 2008-10-29 12:16:52 EDT
To make this package a bit more approachable, I've
expanded the list of files, requires and provides below.

/usr/bin/i686-pc-mingw32-addr2line
/usr/bin/i686-pc-mingw32-ar
/usr/bin/i686-pc-mingw32-as
/usr/bin/i686-pc-mingw32-c++filt
/usr/bin/i686-pc-mingw32-dlltool
/usr/bin/i686-pc-mingw32-dllwrap
/usr/bin/i686-pc-mingw32-gprof
/usr/bin/i686-pc-mingw32-ld
/usr/bin/i686-pc-mingw32-nm
/usr/bin/i686-pc-mingw32-objcopy
/usr/bin/i686-pc-mingw32-objdump
/usr/bin/i686-pc-mingw32-ranlib
/usr/bin/i686-pc-mingw32-readelf
/usr/bin/i686-pc-mingw32-size
/usr/bin/i686-pc-mingw32-strings
/usr/bin/i686-pc-mingw32-strip
/usr/bin/i686-pc-mingw32-windmc
/usr/bin/i686-pc-mingw32-windres
/usr/i686-pc-mingw32/bin
/usr/i686-pc-mingw32/bin/ar
/usr/i686-pc-mingw32/bin/as
/usr/i686-pc-mingw32/bin/dlltool
/usr/i686-pc-mingw32/bin/ld
/usr/i686-pc-mingw32/bin/nm
/usr/i686-pc-mingw32/bin/objcopy
/usr/i686-pc-mingw32/bin/objdump
/usr/i686-pc-mingw32/bin/ranlib
/usr/i686-pc-mingw32/bin/strip
/usr/i686-pc-mingw32/lib/ldscripts
/usr/i686-pc-mingw32/lib/ldscripts/i386pe.x
/usr/i686-pc-mingw32/lib/ldscripts/i386pe.xa
/usr/i686-pc-mingw32/lib/ldscripts/i386pe.xbn
/usr/i686-pc-mingw32/lib/ldscripts/i386pe.xn
/usr/i686-pc-mingw32/lib/ldscripts/i386pe.xr
/usr/i686-pc-mingw32/lib/ldscripts/i386pe.xu
/usr/share/man/man1/i686-pc-mingw32-addr2line.1.gz
/usr/share/man/man1/i686-pc-mingw32-ar.1.gz
/usr/share/man/man1/i686-pc-mingw32-as.1.gz
/usr/share/man/man1/i686-pc-mingw32-c++filt.1.gz
/usr/share/man/man1/i686-pc-mingw32-dlltool.1.gz
/usr/share/man/man1/i686-pc-mingw32-gprof.1.gz
/usr/share/man/man1/i686-pc-mingw32-ld.1.gz
/usr/share/man/man1/i686-pc-mingw32-nlmconv.1.gz
/usr/share/man/man1/i686-pc-mingw32-nm.1.gz
/usr/share/man/man1/i686-pc-mingw32-objcopy.1.gz
/usr/share/man/man1/i686-pc-mingw32-objdump.1.gz
/usr/share/man/man1/i686-pc-mingw32-ranlib.1.gz
/usr/share/man/man1/i686-pc-mingw32-readelf.1.gz
/usr/share/man/man1/i686-pc-mingw32-size.1.gz
/usr/share/man/man1/i686-pc-mingw32-strings.1.gz
/usr/share/man/man1/i686-pc-mingw32-strip.1.gz
/usr/share/man/man1/i686-pc-mingw32-windmc.1.gz
/usr/share/man/man1/i686-pc-mingw32-windres.1.gz

Requires:

libc.so.6()(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libc.so.6(GLIBC_2.4)(64bit)  
libc.so.6(GLIBC_2.7)(64bit)  
libc.so.6(GLIBC_2.8)(64bit)  
libm.so.6()(64bit)  
mingw32-filesystem >= 26
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rtld(GNU_HASH)  

Provides:

mingw-binutils = 2.18.50_20080109_2
mingw32-binutils = 2.18.50_20080109_2-8.fc9
Comment 9 Richard W.M. Jones 2008-10-30 06:04:03 EDT
The only rpmlint output is:

mingw32-binutils.i386: W: non-standard-dir-in-usr i686-pc-mingw32

We've requested an exception for this (bug 468981).
Comment 10 Levente Farkas 2008-10-31 09:52:18 EDT
please remove the:
Provides:       mingw-binutils = %{version}
Obsoletes:      mingw-binutils < 2.18.50_20080109_2-8
lines from this spec file. until these mingw32 packages getting stable i'd like to use old mingw-binutils (which deleted with this lines).
and as none of the other mingw32-* packages use this Provides/Obsoletes why this package should have to be exception?
Comment 11 Richard W.M. Jones 2008-10-31 10:09:43 EDT
What's not stable about this package?
Comment 12 Levente Farkas 2008-10-31 10:44:55 EDT
i mean all mingw32 packages.
but main question here why do you use this Provides/Obsoletes trick in this packages when don't use in any other packages?
currently i'd like to install parallel our old mingw packages and these new ming32 to test and compare them and this's the only place where they conflict.
Comment 13 Richard W.M. Jones 2008-10-31 11:05:56 EDT
So there's a few things to say about this ..

Firstly, it'd be really useful to have you testing the
same mingw32-* packages that we are using (and if you find
bugs, reporting them as you have been doing).  Otherwise
we're going to be chasing pseudo-bugs which are caused by
us running different version.

The provides/obsoletes is needed because we used to ship
mingw-* packages, until FPC asked us to change the names.
However, it's unlikely that anyone still has those ancient
packages installed, so we can probably get rid of those
Provides/Obsoletes.  I only added it to a few base packages.

Also, the HG development repository does allow you to branch
so if you want to make local changes it should be relatively
easy (but remember point 1 above).
Comment 14 Ralf Corsepius 2008-11-01 19:48:21 EDT
I would recommend to add --disable-infos to %configure to avoid wasting time on building the infos.

Finally, I would have approved this package, if it wasn't providing this:
mingw32-binutils(x86-64) = 2.18.50_20080109_2-8.fc10

What is this meant to mean? IMO, it's meaningless.
Comment 15 Richard W.M. Jones 2008-11-02 05:05:52 EST
(In reply to comment #14)

> Finally, I would have approved this package, if it wasn't providing this:
> mingw32-binutils(x86-64) = 2.18.50_20080109_2-8.fc10
> 
> What is this meant to mean? IMO, it's meaningless.

It's added automatically as far as I'm aware.  In this package
we don't override RPM's normal dependency generation.
Comment 16 Ralf Corsepius 2008-11-03 03:50:46 EST
(In reply to comment #15)
> (In reply to comment #14)
> 
> > Finally, I would have approved this package, if it wasn't providing this:
> > mingw32-binutils(x86-64) = 2.18.50_20080109_2-8.fc10
> > 
> > What is this meant to mean? IMO, it's meaningless.
> 
> It's added automatically as far as I'm aware.  In this package
> we don't override RPM's normal dependency generation.

Yes, I meanwhile also noticed. It's FC10's rpm adding more rpm-database bloat and redundancy. IMO, the rpm devs are outsmarting itselves.

APPROVED.
Comment 17 Richard W.M. Jones 2008-11-03 04:14:28 EST
New Package CVS Request
=======================
Package Name: mingw32-binutils
Short Description: MinGW Windows binutils
Owners: rjones berrange
Branches: F-10 EL-5
InitialCC: rjones berrange
Comment 18 Dennis Gilmore 2008-11-03 13:47:06 EST
no need to add owners, co-maintainers to intialCC list they are automatically there by ownership,  it is useful to add you manager if he/she wants to see bugs as they come in.

CVS Done
Comment 19 Richard W.M. Jones 2008-11-06 09:12:07 EST
Build done for F-11:
http://koji.fedoraproject.org/koji/taskinfo?taskID=919444
Comment 20 Richard W.M. Jones 2008-11-06 09:13:11 EST
Done in EL-5:

$ plague-client list uid 684
684: mingw32-binutils (mingw32-binutils-2_18_50_20080109_2-8_el5)  rjones@redhat.com   needsign/success
        xenbuilder2.fedora.redhat.com(i386): 426a863c17dbbe874cce7898ca0ac08cd5d01beb done/done
        xenbuilder2.fedora.redhat.com(x86_64): 46947021c47a18e0393002bd9748f4d71c175b63 done/done
        ppc2.fedora.redhat.com(ppc): d56a79cb0d74d102989a5fad3803b8f918f17db0 done/done
Comment 21 Richard W.M. Jones 2008-11-06 09:14:06 EST
Fails in F-10 at the moment because of the freeze, so I'll
leave this bug open for the time being.
Comment 22 Richard W.M. Jones 2008-11-19 10:49:19 EST
Checked this again, and it still fails in F-10.  Guess we
really do need to wait for the F-10 freeze to end.

Note You need to log in before you can comment on or make changes to this bug.