[Pkg-iscsi-maintainers] Bug#777084: open-iscsi-udeb: please build the udeb on x32

[Christian Seiler]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-iscsi-maintainers/attachments/20151112/cc75c3b1/attachment.sig>