[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On 11.12.2010 17:40, Stephen Kitt 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.

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


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.


Reply to: