On Sat, 2021-05-15 at 16:30 +0200, Cyril Brulebois wrote: > It's just scsi-modules that's not available on armel apparently. > > As far as I know, armel is in “maintenance mode” anyway, trying not > to > lose support for old devices. I wouldn't worry if an optional > component > like open-iscsi(-udeb) would not be installable on this single > architecture. I'll let folks from debian-arm@ comment further on > this. > > But of course, this is a problem that prevents migration now,
> let's > check why; the old Architecture list looked like this (before > switching > it to linux-any): > > Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc > ppc64 > ppc64el s390x > > without armel so you had no installability issue there… Note that > this > was actually explained in the comment just before that line: > > # Note: the (virtual) udeb package scsi-modules (provided by > different > # linux kernel udebs) must exist for these architectures - > so > # check that before adding them to this list; the other > # scsi-(core|common|...)-modules are NOT sufficient! > > An obvious fix would be to revert to an hardcoded list of supported > architectures (and requesting a removal of the obsolete armel binary > that should start appearing in the cruft report[1] once that has > happened); that's not too nice but I don't see any obvious better fix > right now. Yes. That scsi-modules support bites back now. I just forgot about it completely. My intent was to not duplicate another architecture list in d/rules, and in trying to simplify things, it has just fallen apart with this old oddity of support on armel. Time is pressing and I'm wondering what best to do here. I certainly do not care much for the iSCSI support in the installer. I didn't write or test that feature either. And I'm not even sure if that module even works well in the installer. There's 'Root on (iSCSI + DM Multipath)' that I use and care for but that doesn't even get set through the d-i installer. Instead, the setup is to bootstrap the root LUN. Maybe best to rope-in Ubuntu folks. I believe they make use of it in the installer. I personally would like to drop the iSCSI support in the installer, simply because I don't use it and don't have the commitment to support/test it, nor the necessary hands-on knowledge if a bug is reported. But derivatives may have a dependency on it. The current easy fix, as Cyril mentioned above, it to revert it back to the previous architecture list and adapt the same in d/rules in target override_dh_makeshlibs. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: This is a digitally signed message part
