[pkg-wine-party] [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)

[Dmitrijs Ledkovs]

On 17 December 2010 13:45, Matthias Klose <doko at debian.org> wrote:
> On 11.12.2010 17:40, Stephen Kitt wrote:
>>
>> On Sat, 11 Dec 2010 17:28:10 +1030, Ron<ron at debian.org>  wrote:
>>>
>>> On Fri, Dec 10, 2010 at 10:29:24PM +0100, Matthias Klose wrote:
>>>>
>>>> On 23.11.2010 12:49, Dmitrijs Ledkovs wrote:
>>>>>
>>>>> debian-gcc is a bit specific to the native libc based toolchains and
>>>>> cross-toolchains using libc. I didn't manage to find an easy place to
>>>>> plugin mingw-w64 bootstrap into that packaging.
>>>>
>>>> You might want to have a look at Marcin's cross-build packages,
>>>> using the gcc-, binutils- and eglibc- source packages.
>>>
>>> I wasn't aware of Marcin's work, but I also agree this is probably
>>> the best avenue to explore if these are all building from identical
>>> source.  I believe Robert's original attempt even did exactly this,
>>> and I tried to point Stephen in this direction too when he first
>>> contacted me, but I think that point got lost, and I got too busy
>>> to point again in more detail immediately.
>>
>> I'm not sure whether it got lost or not, my packages (with Dmitrijs'
>> contributions) currently build-depend on binutils-source and
>> gcc-4.5-source
>> and avoid duplicating anything from the original binutils and gcc
>> packages; in
>> fact I went to some effort (see my bug reports against gcc-4.5-source, now
>> resolved) to make sure the resulting packages would not only use the
>> tarballs
>> provided in the -source packages but also apply any relevant patches.
>>
>>> AIUI, the main problem with this is that the distro archive tools
>>> currently don't have good support for ensuring these 'binary' -source
>>> packages will remain available and linked to the derivative binary
>>> debs that might be built from them and uploaded to the distro.
>>>
>>> I believe ftp-master indicated to Robert that this could be fixed,
>>> but he went back to the quick and dirty duplication instead.  If
>>> there are people with time to spend on this, talking to the archive
>>> maintenance people about what needs to be done for that, and when
>>> and how it might happen, is probably a productive step at this point.
>>
>> Indeed; I'm not sure what Matthias means by
>>
>> On Fri, Dec 10, 2010 22:29:24 +0100, Matthias Klose<doko at debian.org>
>>  wrote:
>>>
>>> this is already guaranteed by the gcj and gnat builds by only relying on
>>> the tarball in the gcc-4.x-source package.
>>
>> I imagine this could mean that the gcj and gnats builds don't use the
>> patches
>> in the gcc-4.x-source package, and only use the tarball which won't change
>> from one Debian version to another (e.g. 4.5.1-1 to 4.5.1-2 etc.)...
>
> yes.
>
>> That
>> seems a shame to me since the patches are useful, and it still leaves the
>> problem of having a package build using gcc-4.5-source 4.5-1 for example,
>> and
>> then gcc-4.5-source being replaced with version 4.5.1-1 with a new
>> tarball.
>
> no, the tarball doesn't change. it's in the .orig.tar.gz. all other
> patches/packging are synced with the gcc-4.5 package. Nothing is lost, all
> patches are applied.
>
>> The other solution based on Marcin's work, which is also readily supported
>> by
>> the existing -source packages, requires that the target architecture be
>> understood by dpkg (as pointed out by Dmitrijs); that may be a worthwhile
>> goal, notably since it solves the problem of how to provide build packages
>> for the various libraries people find useful, but it's a much longer-term
>> goal as far as I can see...
>
> otoh, this approach breaks more often with updates on patches and packaging.
> Manageable however.
>

I have been running the daily build of gcc-4.4 trunk, binutils-trunk
with mingw-w64-trunk and there were no breakages (if something was
broken it was fixed within 24h by any one of these packages). So I
believe it will be manageable. I'm pending inclusion of mingw-w64
triplet. See debbug #606825.

>  Matthias
>