when can a package be made architecture-dependent?
I'm cc'ing this to debian-policy, because the issue in the subject line
seems like an important general question.
To summarize (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=176627): I
reported a bug for mingw32 (a Linux->Windows cross-compiler) because the
developer had declared it architecture-dependent for no technical reason
that I could understand, and I wanted to run it on Debian/powerpc.
He (Ron Lee <ron@debian.org>) responded:
> Well.. spirit or none there are such things as unsupported architectures.
>
> That said though, you are quite correct in that there should be no
> technical reasons why it should remain that way for this package.
> From a practical point of view though, this is unlikely to change
> in the near future unless you either:
>
> a) do the work.
> b) find someone else with the right hardware prepared to do the work.
> c) buy me a fast new PPC laptop.
>
> I can quite sympathise with what you want, but I'm not going to
> make this package arch-any just so it can break on every arch
> except i386 (and hence keep it out of testing for everyone).
> That's not the sort of equality we're aiming for.
Actually, I thought that *was* the sort of equality Debian was aiming
for...if it breaks for any architecture, it's a serious problem that
everyone has to deal with. If every Debian developer refused to support
architectures he/she didn't have immediate access to, non-x86 Debian would
disappear pretty quickly.
Of course, it's a different matter if the upstream package is inherently
non-portable (written in x86 assembler for an x86 target, for
example); I can understand the need for architecture-dependent packages in
that case...
Here, however, the only code that is actually compiled for a non-x86 host
is gcc/binutils--and if they don't work as a cross-compiler on a supported
platform like ppc, it's a serious bug that needs to be passed upstream.
The mingw32-runtime, etc., are all cross-compiled for an x86 host, so if
they compile somewhere they should compile anywhere (if not, it's a gcc
bug).
> Realistically, probably the best I can offer is that if you can
> give me a confirmed successful build report, I'll add PPC to the
> list of target arches. If not, I'd suggest you talk to the folks
> at mingw.org about their procedures for accepting patches.. :-)
Done. I'm using the packages from unstable. As I expected, there were no
intrinsic portability problems...the only obstacles were in the packaging.
mingw32-binutils built & installed with no problems.
The main problem with mingw32 and mingw32-runtime, of course, is the
circular dependency. I understand the reason for this, but to get things
up and running I just manually unpacked the mingw32-runtime i386 package
and copied the files onto my system, deleted the dependencies from
debian/control, built & installed mingw32, re-built mingw32-runtime,
deleted the copied runtime, then installed the runtime .deb. The right
thing to do, however, is to simply tag the mingw32-runtime package as
architecture-independent, because it is!
I learned the hard way, by the way, that mingw32-runtime from
Debian/stable does not work (there's a missing library, I forget which);
you need to put a version number in mingw32's Build-Depends.
Also, there is a bug in mingw32's debian/rules file: you used
$(target)-strip to strip {cc1,cc1plus,cpp0,tradcpp0}, which is incorrect
since those are host binaries, not target (i586) binaries. I changed that
line to use 'strip' (probably you should use dh_strip).
Otherwise it went smoothly, and the resulting .deb's (built for
Debian/testing) are at:
http://jdj.mit.edu/~stevenj/mingw32/
Given the corrections above, there is no reason why mingw32 won't build
as-is on every Debian architecture. (If it doesn't, it's a bug in gcc.)
I hope this can happen in the near future.
Steven
Reply to: