[OpenWrt 18.06] LuCI can install packages even those which are in conflict

In my case, file /sbin/ntpd is provided by busybox. When I want to install ntpd package with opkg it ends up with:

root@router_name:~# opkg install ntpd
Installing ntpd (4.2.8p11-1.0) to root...
Downloading ****/ntpd_4.2.8p11-1_aarch64_cortex-a53.ipk
Installing ntp-utils (4.2.8p11-1.0) to root...
Downloading ****/ntp-utils_4.2.8p11-1_aarch64_cortex-a53.ipk
Configuring ntp-utils.
Collected errors:
 * check_data_file_clashes: Package ntpd wants to install file /sbin/ntpd
        But that file is already provided by package  * busybox
 * opkg_install_cmd: Cannot install package ntpd.

When I go to LuCI and in System → Software, I want to download and install package ntpd and once I press OK, then the LuCI doesn’t have any problem with conflict.

Installing ntpd (4.2.8p11-1.0) to root...
Downloading ****/ntpd_4.2.8p11-1_aarch64_cortex-a53.ipk
Configuring ntpd.

Here is the output of opkg list-installed:

root@router_name:~# opkg list-installed | grep ntpd
ntpd - 4.2.8p11-1.0

And indeed right now /sbin/ntpd is provided by that package. You can see even the difference in help.

[Cynerd]

@jow- I don’t think that that is true. I am not saying that you personally seen some issue for exactly this I am just saying that this can cause other issues and hides underlying problem.

The issue I see this can cause is when user tries to upgrade some package. In general upgrades are not supported in OpenWRT because they are broken. But they are broken because of decisions like these! So you can’t just say: nobody complains about not be able to install packages they want. It is more about what is right and this is just wrong. You are breaking system without telling it to user. User with good intentions installs some package and you, instead of informing him that it is something that is not easily done, just do it and effectively break system to him.

Note that this is not just some inconvenience but rather pretty significant bug. You are forcing opkg to install package that should effectively be not there. Opkg, because it is not clever enough, looses track of which package owns given file and it is effectively random. If there is for example light and heavy variant of same library and you install them and later install some application able to run only with heavy version then such application can be broken. In such case there is nothing wrong with opkg nor with packages it installed. The cause is that you are setting up system to broken state and you are telling us here that it is ok solution?

I think that this patch should be accepted and users should be notified about that. This is same level of error such as collision between packages caused by Conflicts: (which btw is also ignored?). Solution should either happen automatically or it should be up to the user. Any solution of “let’s ignore it” is just wrong.

[jow-]

This is intentional and will be kept for the time being until the package universe is mature enough to handle alternatives, conflicts and replacements cleanly.