Can a package configured as `m` clash with another package in the install step of `make`?

For Developers
1

I have one package configured as m, the other configured as y in the configuration, but make fails in the install step with clashing packages.

Is that correct or some bug? -- Usually, conflicting packages can be build, but just cannot be installed at the same time, and when a package is configured as m it does not get installed when running make, and later in the running system the user can uninstall the one and install the other packager.

Here I have

CONFIG_PACKAGE_kmod-ath10k=m
CONFIG_PACKAGE_kmod-ath10k-ct=y
CONFIG_PACKAGE_kmod-ath10k-ct-smallbuffers=m

and make -j1 V=sc bails out with

[...]
Collected errors:
 * check_data_file_clashes: Package kmod-ath10k-ct-smallbuffers wants to install file /o/build_dir/target-i386_pentium-mmx_musl/root-x86/lib/modules/5.4.111/ath10k_core.ko
	But that file is already provided by package  * kmod-ath10k-ct
 * check_data_file_clashes: Package kmod-ath10k-ct-smallbuffers wants to install file /o/build_dir/target-i386_pentium-mmx_musl/root-x86/lib/modules/5.4.111/ath10k_pci.ko
	But that file is already provided by package  * kmod-ath10k-ct
 * opkg_install_cmd: Cannot install package kmod-ath10k-ct-smallbuffers.
[...]
make[2]: *** [package/Makefile:69: package/install] Error 255
[...]

(As a workaround which would not bother me anyway I can just completely disable the kmod-ath10k-ct-smallbuffers here.)

2

From memory you need to make all three 'm'

1 Like
3

From memory you need to make all three 'm'

What is the reason? Reads like that even an m-package does install stuff in the image. Why?

And what to do if I want to have one (e.g. kmod-ath10k) pre-baked into the image, but give the user the ability to switch to the other (e.g. kmod-ath10k-ct or kmod-ath10k-ct-smallbuffers) later?

4

It's been a while but from memory. y implies the module is built-in into the kernel and can't be replaced.

However m implies it is module and it can be installed at runtime.

So by using m you can install different modules at runtime. If you use y the module is permanent and built-in to the kernel

5

It's been a while but from memory. y implies the module is built-in
into the kernel and can't be replaced.

However m implies it is module and it can be installed at runtime.

So by using m you can install different modules at runtime. If you
use y the module is permanent and built-in to the kernel

I thought in OpenWRT's confit m means that a
.ipk-package is built but not installed into the OpenWRT image by
default; y means that it is installed into the OpenWRT image by
default. Both as a loadable kernel module.

Not to be confused with the meaning of y and m in the
kernel's config.

Is it for kernel modules in the OpenWRT's config different?

And if so, how can one then differentiate between

  • Build it as .ipk-package but do not bake it into the image by
    default,
  • also bake it into the image by default?
6

Are you using CONFIG_TARGET_PER_DEVICE_ROOTFS=y.

7

I think your correct
My memory is getting worse

8

On Fri, 04 Jun 2021 14:56:14 +0000, Kabuli Chana via OpenWrt Forum mail@forum.openwrt.org wrote about "[OpenWrt Forum] [For Developers] Can a package configured as m clash with another package in the install step of make?":

Are you using CONFIG_TARGET_PER_DEVICE_ROOTFS=y.

No; I even can't select it for my target, grep TARGET_PER_DEVICE_ROOTFS .config gives empty output.

But this problem was more due to some inconsistency the build system got in; after removing tmp/ in the OpenWRT source directory I could build it without problems. So it was a spurious problem caused by something else which I could not track down.

9

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

1 Like
10

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.