Bug#1005959: mig-for-host:amd64 should not exist
Helmut Grohne, le dim. 20 févr. 2022 07:50:59 +0100, a ecrit: > Once doing that, we effectively get the very same packages just > without -linux or -kfreebsd. Yep, that's what I understood > 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? For now we'll probably build such hurd-amd64 packages on amd64 anyway. > > 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. Yep. > If you agree with this change in principle, I can look into writing a > patch for it. If you're interesting in having a look you're welcome, otherwise I believe I see how to change things. Samuel
Bug#1005959: mig-for-host:amd64 should not exist
Hi Samuel, On Sun, Feb 20, 2022 at 12:01:36AM +0100, Samuel Thibault wrote: > Mmm, it still targets hurd- 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
Bug#1005959: mig-for-host:amd64 should not exist
Hello, Helmut Grohne, le ven. 18 févr. 2022 14:13:09 +0100, a ecrit: > On Fri, Feb 18, 2022 at 12:45:57PM +0100, Guillem Jover wrote: > > Just to spell out, what might perhaps be obvious here, but I think > > they key is that MIG is "kernel independent", so it provides an > > interface which is none- which means it can be used on any- > > to target hurd-. Perhaps this should be mentioned in the packages > > description, because otherwise I agree it seems a bit confusing? > > Thank you. In that case, I think it shouldn't be mig-x86-64-linux-gnu > nor mig-x86-64-gnu nor mig-x86-64-kfreebsd-gnu, but simply mig-x86-64 as > that's what it is specific to. Mmm, it still targets hurd- explicitly, so I'd say it should still be called mig-x86-64-gnu. 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 checking for i686-gnu-mig... i686-linux-gnu-mig but that's still relatively bogus. Samuel
Bug#1005959: mig-for-host:amd64 should not exist
Control: tags -1 + moreinfo Hi Guillem, On Fri, Feb 18, 2022 at 12:45:57PM +0100, Guillem Jover wrote: > Just to spell out, what might perhaps be obvious here, but I think > they key is that MIG is "kernel independent", so it provides an > interface which is none- which means it can be used on any- > to target hurd-. Perhaps this should be mentioned in the packages > description, because otherwise I agree it seems a bit confusing? Thank you. In that case, I think it shouldn't be mig-x86-64-linux-gnu nor mig-x86-64-gnu nor mig-x86-64-kfreebsd-gnu, but simply mig-x86-64 as that's what it is specific to. That makes a few downstream-implications a little more difficult though. The binary would likely have to be called x86_64-mig instead of x86_64-gnu-mig. mig-for-host can likely stay as it is. I suppose such renaming would break downstreams such as hurd as they don't expect such changed names. At this point I'm unsure whether such a renaming effort would be a useful thing to spend time on. However improving the description would be useful. Helmut
Bug#1005959: mig-for-host:amd64 should not exist
Hi! On Fri, 2022-02-18 at 09:42:12 +0100, Samuel Thibault wrote: > Helmut Grohne, le ven. 18 févr. 2022 06:20:45 +0100, a ecrit: > > I'm quite surprised about the existence of mig-for-host:amd64 and > > mig-x86-64-linux-gnu. I'm also a little little surprised about > > mig:amd64. Are you sure that these are correct? > Well, they have the same role as their i386 counterparts :) > > The gnumach kernel has had an experimental 64bit port for some time. > We're seeing some patches approaching that will make it something people > can try and hack on. But to be able to build it easily one needs a 64bit > mig. > > Actually possibly for building a gnumach that is 64bit but can take > 32bit userland we'll need both a 64bit and a 32bit mig installed to > support both RPC worlds. Just to spell out, what might perhaps be obvious here, but I think they key is that MIG is "kernel independent", so it provides an interface which is none- which means it can be used on any- to target hurd-. Perhaps this should be mentioned in the packages description, because otherwise I agree it seems a bit confusing? Thanks, Guillem
Bug#1005959: mig-for-host:amd64 should not exist
Hello, Helmut Grohne, le ven. 18 févr. 2022 06:20:45 +0100, a ecrit: > I'm quite surprised about the existence of mig-for-host:amd64 and > mig-x86-64-linux-gnu. I'm also a little little surprised about > mig:amd64. Are you sure that these are correct? Well, they have the same role as their i386 counterparts :) The gnumach kernel has had an experimental 64bit port for some time. We're seeing some patches approaching that will make it something people can try and hack on. But to be able to build it easily one needs a 64bit mig. Actually possibly for building a gnumach that is 64bit but can take 32bit userland we'll need both a 64bit and a 32bit mig installed to support both RPC worlds. Samuel
Bug#1005959: mig-for-host:amd64 should not exist
On Fri, 18 Feb 2022, 5:21 pm Helmut Grohne, wrote: > Package: mig-for-host > Version: 1.8+git20200618-9 > User: helm...@debian.org > Usertags: rebootstrap > > Hi Samuel, > > I'm quite surprised about the existence of mig-for-host:amd64 and > mig-x86-64-linux-gnu. I'm also a little little surprised about > mig:amd64. Are you sure that these are correct? I think none of them > should exist, because they all imply Linux rather than Mach. Can you > shed some light as to why they should exist? If not, please remove them. > Hi Helmut, MIG is a build tool, and is required to build the HURD from a GNU/Linux system. It therefore needs to support the same architectures as the buildd. Thanks for confirming! >
Bug#1005959: mig-for-host:amd64 should not exist
Package: mig-for-host Version: 1.8+git20200618-9 User: helm...@debian.org Usertags: rebootstrap Hi Samuel, I'm quite surprised about the existence of mig-for-host:amd64 and mig-x86-64-linux-gnu. I'm also a little little surprised about mig:amd64. Are you sure that these are correct? I think none of them should exist, because they all imply Linux rather than Mach. Can you shed some light as to why they should exist? If not, please remove them. Helmut
