Re: Upcoming FTPMaster meeting

[Guillem Jover <guillem@debian.org>]

Hi!

On Mon, 2011-02-14 at 08:39:21 +0100, Raphael Hertzog wrote:
> On Sat, 12 Feb 2011, Guillem Jover wrote:
> > Using Build-Architecture would be a workaround, it should not be
> > needed once multiarch is in place and those packages are built for
> > their respective architectures.
> 
> While technically true, this can be discussed. I can imagine that you
> might not want to configure multiarch on your system just because you
> need some bootloaders files (e.g. syslinux-common in a CD build process).
> 
> Using multi-arch to solve this problem means changing the package from
> arch: all to arch: i386 (or the specific arch set that you're interested
> in).

Well that's precisely one of the cases multiarch is designed for, so I
don't see why we'd not use it there.


To clarify a bit my remark and complement what Philipp mentioned, there's
mainly two kinds of packages that could require Build-Architecture:

1) Firmware for emulators

Or just code that does not get run by the host, and requires a
cross-compiler if not built on the host. Things like seabios, bochsbios,
openbios, openhackware, proll, but not vgabios (which uses bcc/bin86,
a kind of cross-compiler by design). This would get switched to arch:foo
from arch:all. The packages needing them would pull them. And yes this
requires changing the arch, but it's the correct thing to do (the other
valid option in my mind would be to have cross-compilers available and
keeping them as arch:all, but we don't). This only has the slight
inconvenience that apt would need to pull the Packages files for all
involved architectures, but filtered Packages files could be provided,
as hinted by Steve.

2) Bootloaders

Or just code that gets run by the host, although possibly in another
processor mode. Things like grub, syslinux, etc. This is currently
handled by the bi-arch toolchains, and I'd expect it to continue being
the case for quite a while after multiarch deployment, or at least I
don't see the freestanding bi-arch compiler bits disabled immediately
if at all, or ever?


So the case you mention using a bootloader for a CD is a mix of both
1) and 2), which although keeping syslinux-common as arch:all might
work somehow ok, it'd not be possible for something like grub2 which
can boot from CD too for example, but goes beyond the bi-arch realm.
So the correct eventual solution, seems to me to switch any such
package from arch:all to arch:foo.

regards,
guillem