These drivers depend on the corresponding net drivers, or at least
common modules built under drivers/net/ethernet, currently leading
to duplicate modules.
I don't want to resolve this by adding a dependency between
nic-modules and scsi-modules, as that would pull in both into
installer images that previously only needed one set of drivers. I
also don't want to add the common modules into kernel-image as that
would bloat all installer images. Instead, put the drivers in a new
package and we can work out which installer images should include it
later.
Build scsi-nic-modules for all architectures/flavours that build
scsi-modules using the common module list now.
This will allow to get graphics support in VM instances right from
Debian installer phase.
(cherry picked from commit fb11c71e7c36b2e9abb7535e6c9c0ddbb8dc7c15)
I failed to notice that ppc64 had a symlink to powerpc's package-list
which overrode the dependencies for nic-pcmcia-modules. For now,
duplicate that override for ppc64. In the longer term the powerpc*
net driver packages should be reorganised to match other
architectures.
Fixes FTBFS.
The drivers in pata-modules depend on libata, which depends on scsi_mod.
The corresponding package dependencies pata-modules -> ata-modules
-> scsi-core-modules are already defined, and there is no sense in
adding a direct dependency from pata-modules to scsi-core-modules.
The usb-storage driver depends on scsi_mod in scsi-core-modules, not
any of the drivers in scsi-modules.
Merge the configuration and default-configuration directories,
using per-architecture overrides in package-list.
This requires a newer version of kernel-wedge to support
Depends_<arch> properly.
The only immediate change to debian/control is to remove the
different description for nic-modules on sparc64.
- Drop patches already in 4.16
- Overwrite changes on master to debian/installer, which were also
applied on sid and then changed
- [x86] Fix up dell_smbios configuration; now it's a single driver
selected by DELL_SMBIOS, with DELL_SMBIOS_{SMM,WMI} being boolean
options
- Clean up configuration with kconfigeditor2
So many module packages depend on core-modules already that almost
every installer image includes it.
The only obvious exceptions are the sh4 installer builds, as there
was no core-modules package on sh4. For consistency, include the
default set of modules in its kernel-image package now.
There is still duplication between core-modules and usb-modules, and
they actually have a circular dependency due to gpio-viperboard
driving (part of) a USB device.
- Add core-modules as a dependency of usb-modules
- Remove gpio-viperboard from core-modules as it is unlikely to be needed
We currently FTBFS on mips64el:
cannot read /tmp/linux/linux-3.16.2/debian/installer/mips64el/modules/mips64el-sb1-bcm91250a/mips64el-sb1-bcm91250a
...
cannot read /tmp/linux/linux-3.16.2/debian/installer/mips64el/modules/mips64el-loongson-3/mips64el-loongson-3
...
find: `debian/speakup-modules-3.16-1-loongson-3-di': No such file or directory
speakup-modules-3.16-1-loongson-3-di will be empty
The 'cannot read' warnings are due to a bug in kernel-wedge
copy-modules (fixed in version 2.90) that affects module list
directories that are symlinked. Instead of getting a list of files
and symlinks in the directory, it only finds the directory-symlink.
The bug was generally harmless because copy-modules also gets a
list of inter-package dependencies (without relying on the first
list), and this includes all package names. Except that
speakup-modules has 'Depends: kernel-image!', and as there is
no package definition for 'kernel-image!' this dependency is
not included in the second list and copy-modules does not see
'speakup-modules'.
mips64el seems to be the only architecture which has a symlink to a
module list directory including speakup-modules.
Delete the '!'.
svn path=/dists/sid/linux/; revision=21834
Ben Hutchings
Marcin Juszkiewicz
James Clarke
Ben Hutchings