Re: [pkg-wine-party] [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
On 11 December 2010 16:40, Stephen Kitt <steve@sk2.org> wrote:
> On Sat, 11 Dec 2010 17:28:10 +1030, Ron <ron@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.
>
I was using the same strategy independly from Stephen with my original
mingw-w64-toolchain package which is on launchpad. The only difference
is that I was supporting both *-source packages and vcs checkouts for
daily builds, which has now stalled due to bzr issues on launchpad.
Overall the build strategy was about the same, sans some minor
details.
>> 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@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.)... 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.
>
> Matthias, is that what you meant?
>
As far as i can see from the build-logs source uploads of gcj / gnat
use corresponding -source package and they do apply updated patches
from the new -source package. The tarball is changed rarely, instead
svn-updates patch is regenerated on subsequent uploads by Matthias.
> I'll take it up with ftpmaster as you suggest, Ron!
>
> 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...
>
And it also solve the gcc package splitting problem (cpp, gcc, gcj, gnat etc)
I have created a reprepro for mingw-i386 and mingw-amd64 on my alioth
account and I'm building mingw-i386 packages using dpkg-buildpackage
using -a option. I have updated dpkg_share files.
I will try bootstrapping the arch again in pbuilder based on Debian
experimental and then start uploading.
It would be best to have access to a mingw-w64 alioth project. I have
submitted the request for that, but still haven't received a reply.
But that is another issue.
I'll start mingw-common package on collab-maintainance with helper
scripts, policy and updated dpkg-share.
Repurposing Marcin's package for mingw is still work in progress.
> Regards,
>
> Stephen
>
Reply to: