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

[Matthias Klose]

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.

   Matthias