Bug#1005959: mig-for-host:amd64 should not exist

[Helmut Grohne <helmut@subdivi.de>]

Hi Samuel,

On Sun, Feb 20, 2022 at 12:01:36AM +0100, Samuel Thibault wrote:
> Mmm, it still targets hurd-<any> explicitly, so I'd say it should still
> be called mig-x86-64-gnu.

I can relate to that, yes.

> What I'm wondering is why we added -linux/-kfreebsd since here they are
> host, not target. The package name is supposed to designated the target
> doesn't it?  I'm actually now unsure what "mig-for-host" was supposed to
> mean.  AIUI we'd want it to pull a native-for-host binary that targets
> the architecture equivalent on the hurd port. E.g. on linux-amd64 it'd
> pull a linux-amd64 x86-64-gnu-mig binary.  Currently gnumach is fine
> with this

I think the -linux/-kfreebsd ones originate from the fact that you used
any-amd64. In the end, there will be a sparsely filled binary matrix of
builds.

I see how the build/host/target terminology can become confusing here.
It depends on the point of view. mig's point of view, host is what
architecture the built mig is being run on, but the target architecture
is what architecture it is being used for. The downstream packages
(mainly hurd) relate to mig via their host architecture though. Thus the
"-for-host" part is hurd's host, but mig's target in a sense.

So why do we have mig-for-host? We want hurd to depend on some mig for
its host architecture (i.e. a mig where build=don't care, host=don't
care, target=host of hurd). And that directly means, we only need
mig-for-host for hurd-any. How about changing its architecture field
from "any-i386 any-amd64" to "hurd-any"?

Then, mig-x86-64-linux-gnu has no reverse dependencies anymore and can
go way. Unfortunately, that also means that we won't have any mig
executable on amd64 anymore, but having it would be useful for cross
building hurd. To fix that, we can change the Architecture field of
mig-x86-64-gnu from "hurd-amd64" to "any-amd64". Once doing that, we
effectively get the very same packages just without -linux or -kfreebsd.

Circling back to this matrix of builds. It has two dimensions (host
architecture and target architecture). In the packaging, we decide which
of these combinations generate a package by default. Of course the
diagnoal (host==target) is needed. There is no question about that, but
for other combinations it is less obvious. You currently try to fill
same-cpu combinations. I'm wondering whether that is needed (given that
rebootstrap builds its own mig anyway) and I'm wondering whether that
should be expanded to just cover the full matrix withing x86
architectures (32bit and 64bit) to ease hurd-amd64 development on
hurd-i386. Do you have a preference here?

> checking for i686-gnu-mig... i686-linux-gnu-mig
> 
> but that's still relatively bogus.

After the change above, there would not be any i686-linux-gnu-mig, but
i686-gnu-mig instead.

If you agree with this change in principle, I can look into writing a
patch for it.

Helmut