On 11/12/2015 01:16 AM, Adam Borowski wrote: > On Tue, Nov 10, 2015 at 02:55:34PM +0100, Christian Seiler wrote: >> I've looked at a build log of the 'linux' package on x32 and saw that >> only some header packages are built there. Does that mean that the >> amd64 kernel packages are used on x32? (Also in d-i?) > > d-i is not capable of using a foreign arch kernel. Multiarch support in d-i > has been promised for many years but is still vaporware, and even if it > comes, it deals with packages for the installed system rather than kernel > for booting d-i itself. Thus, my version of the x32 port uses native kernel > udebs; using foreign ones would be possible in principle but would 1. > require a large amount of work, and 2. be fragile because of the need to > force a kernel cmdline string at all times. > > Such a set of udebs exists on http://debian-x32.org; the patches are still > rotting in the BTS. I guess I should re-check then and ping; I admit I > haven't looked at new d-i development in several months though.
Ok, so the current state of the port is that there is no official d-i support for it in the archive at all, and that there are still unsolved issues w.r.t. the kernel in general, if I understand that correctly. >> If that really is the case, since amd64 builds the linux-modules udeb, I'd >> be perfectly happy to merge support there and fix this bug. > > Are you moving iscsi support there? Or is it going to be kept built by > src:open-iscsi like currently? If the latter, building the udeb on x32 > can't hurt release architectures... So the udeb won't change, it will continue to be built by src:open-iscsi. The 'scsi-modules' udeb package is the kernel udeb that contains the necessary modules for (among other things) iSCSI, so that the userspace implementation in the udeb will actually work at all. The problem I see is that if I add the string "x32" to the list of architectures for the udeb, src:open-iscsi will build a binary package on an architecture that is not installable at all (because dependencies can't be resolved). If x32 were to become an official release architecture tomorrow, this would immediately prevent testing migration of the open-iscsi package. Of course, it currently isn't, and solving the question about what to do with the kernel is probably a prerequisite to making it a release architecture, so the danger there is probably very slim. Still, I'm kind of hesitant to add something to the package that could blow up some time in the future. On the other hand, I want to support porting efforts and do understand that sometimes things like this can be chicken-or-egg problems (i.e. you need to have a sufficiently diverse set of udebs to be actually able to work on d-i support for the specific port and test things). Since I don't see a clear-cut answer, I'm going to defer to you here, since you are working on the port. If you say that it helps you in your efforts to just have this in the archive, even though on the not yet official x32 architecture the package is not installable, I'll add it to debian/control and close this bug. The other possibility would be to block this bug against some other bug that tracks x32 d-i work. Please tell me which way you'd prefer. Thanks, Christian
signature.asc
Description: OpenPGP digital signature
