Hi Maintainer,

rejected. Good god.

- One of the first points is - you overwrite / jump into other packages
  namespace with this. 
			Source: ia32-alsa-lib
			Binary: lib32asound2
            lib32asound2 is built by alsa-lib (for amd64).
  If this is ever going to happen like this you need to have a namespace
  that doesnt kick out existing packages. Or show, in whatever way, that
  the maintainers of the package you want to convert actually do want to
  hand it over to you.

- The included complete copy of the source *and* the existing i386
  binary is something that is really bad. Yes, we get in trouble if we
  don't include the source for packages on the archive, but it is still
  a *very* strong point against this packaging scheme.
  We (as in ftp-team), but even more the security team are against them.

- How about you do not provide the ia32-foo packages yourself, but leave
  that to the maintainers? Just provide the tools to *easily* create
  them at build time. That would be the best way to go. It would enable
  basically every package (where it makes sense) to have an ia32
  version, do not double the source code needlessly, etc. Win win.


- Besides the above points I got a mail a day ago about your packages,
  which I quote (almost) completly, giving some more reasons why the
  packages aren't accepted right now (and point #3 is really WTF!):

1/ No toolchain support

We already build a hppa64 cross compiler on hppa, a spu-elf
cross-compiler on powerpc and ppc64, and some biarched libs for amd64,
i386, kfreebsd-amd64, mips, mipsel, powerpc, ppc64, s390, sparc. We
support building a hppa64 kernel on a 32-bit hppa kernel, we support
building SPU (Cell) binaries on any powerpc, we support building 64-bit
binaries on all biarched 32-bit arch (and even running it if there is a
64-bit kernel) and building and running 32-bit binaries on all biarched
64-bit arch. But we don't support ia6432 biarch at all. There is no
cross-compiler built, and no "native" way to build ia32 binaries on
ia64. If they were, the packages from ia32-gcc-4.3 would be provided by
gcc-4.3, the packages from ia32-glibc would be provided by glibc.


2/ The source packages include the source packages from which they use
   binaries

Which mean ia32-gcc-4.3 includes the .dsc, .diff.gz and .orig.tar.gz
from gcc-4.3, same for other ia32-* packages. In short, this bloats the
archive. Just for the record:

43M gcc-4.3_4.3.0.orig.tar.gz
15M glibc_2.7.orig.tar.gz


The solution here would be to provide a tool which is able to live get
i386 binaries, build ia64 (or even arch:all) packages from them, and
propose to install them. Having those binaries twice with the sources
twice in the archive is totally pointless.


3/ No README.Debian

There is no indication whether how to run ia32 binaries on ia64, so no
indication whether how to use those packages. I asked Goswin von
Brederlow if he knew how to run them. He doesn't know. I asked him how
did he tested the packages, he answered that someone (he can't remember
who) told him on #debian-devel it worked.


4/ Hard to handle for security team

Those packages are not built from sources. This make them hard to handle
for the security team.


5/ Uploaders filed

Maintainers and Uploaders from $foo package are added to ia32-$foo's
Uploaders without noticing them. I'm not quite sure Aurelien Jarno wants
to maintain ia32-glibc. I'm not quite sure Matthias Klose wants to
maintain ia32-gcc-4.3.



-- 
bye Joerg