Bug 454408 (mingw32-binutils)

(In reply to comment #0)
> ... the host set to i686-pc-mingw32.
You mean --target :)

Clean package, nothing much to say about it.

APPROVED.

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)

(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.

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.

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

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.

Spec URL: http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=918e9f907e958fdbc2016dcc5e36bf4099800bd7;path=/binutils/
SRPM URL: http://www.annexia.org/tmp/mingw/fedora-9/src/SRPMS/mingw32-binutils-2.18.50_20080109_2-8.fc9.src.rpm

This is the latest version, updated to conform with the
approved packaging guidelines:

http://fedoraproject.org/wiki/Packaging/MinGW

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

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).

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?

What's not stable about this package?

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.

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).

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.

(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.

(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.

New Package CVS Request
=======================
Package Name: mingw32-binutils
Short Description: MinGW Windows binutils
Owners: rjones berrange
Branches: F-10 EL-5
InitialCC: rjones berrange

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

Build done for F-11:
http://koji.fedoraproject.org/koji/taskinfo?taskID=919444

Done in EL-5:

$ plague-client list uid 684
684: mingw32-binutils (mingw32-binutils-2_18_50_20080109_2-8_el5)  rjones   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

Fails in F-10 at the moment because of the freeze, so I'll
leave this bug open for the time being.

Checked this again, and it still fails in F-10.  Guess we
really do need to wait for the F-10 freeze to end.

Built in F-10:

https://admin.fedoraproject.org/updates/mingw32-binutils-2.18.50_20080109_2-10.fc10