14628 2021-11-12 18:24:35 +0000 opkg incorrectly fails to upgrade packages when an owned file has been transferred to a dependency. 2023-01-26 16:17:10 +0000 1 1 6 Yocto Project Subprojects opkg opkg 0.4.5 x86 Multiple ACCEPTED Undecided normal next-minor 1 alex.stewart alex.stewart dylan.turner --- --- No (bug/feature does not impact docs) oldest_to_newest 91996 0 4843 alex.stewart 2021-11-12 18:24:35 +0000 Created attachment 4843 Reproducing regression test Suppose a system has installed pkgs 'a_1' and 'b_1', where 'a' depends on 'b'. Pkg 'a_1' owns a file '/conflict_file'. Suppose the feed contains pkgs 'a_2' and 'b_2', with similar dependencies. However, in the *version 2* relationship, ownership of '/conflict_file' has been moved from 'a' to 'b'. The package maintainers have correctly asserted that 'b_2' conflicts with 'a (<<2.0)'. When the user asks that opkg install 'a_2', either by upgrade or directly, opkg *should* identify that it must also install 'b_2', and that 'b_2's ownership of '/conflict_file' doesn't impact 'a_1', because 'a_1' is being uninstalled. However, opkg instead fails and - when using libsolv - reports the file conflict as the cause. The attached python test reproduces this error. This bug reproduces using both the internal solver and libsolv. It only needs to be solved for libsolv. This bug has been migrated from NI's internal backlog. 94815 1 dylan.turner 2023-01-26 16:17:10 +0000 This issue happens because essentially, opkg is trying to install packages (other than the primary one) too early. b_2 is getting installed before a_1 can be removed and replaced with a_2. The conflict occurs because unlike dpkg, opkg does not make a backup of files to restore, instead attempting to catch and handle potential file conflicts before installing the final package. Some of these, like file ownership transfer in an upgrade scenario, are handled, but not so with file ownership transfer to a completely different package as in this bug. This is an issue that any lightweight package manager could run into because it's a result of not having enough information about the resulting file system in order to fix the conflict. It may be possible for a quick fix similar to what happened for another case as seen in "check_data_file_clashes_change" in opkg_install.c, but really, a more thorough solution is probably needed. Two potential options are: 1) implementing a backup system like dpkg where we do the install and check for conflicts after, backtracking if there's an actual issue. - This is not that lightweight however, so it may not be a good option for opkg, hence the reason it's not currently used. 2) implementing a system that can do a calculation of the final file system to check before our current conflict check 4843 2021-11-12 18:24:35 +0000 2021-11-12 18:24:35 +0000 Reproducing regression test issueV2.py text/x-python 1931 alex.stewart IyEvdXNyL2Jpbi9lbnYgcHl0aG9uMwojIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w LW9ubHkKIwojIFdoYXQgc3RlcHMgd2lsbCByZXByb2R1Y2UgdGhlIHByb2JsZW0/CiMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKIwojIDEuIHBrZyAnZm9vJyBvd25zIGEg ZmlsZSBjYWxsZWQgJ2NvbmZsaWN0X2ZpbGUnIGFuZCBkZXBlbmRzIG9uIHBrZyAnYmFyJwojIDIu IHBrZyAnZm9vJyBhbmQgJ2JhcicgYXJlIGluc3RhbGxlZC4KIyAzLiBwa2cgJ2Zvb18yJyBpcyBh ZGRlZCB0byB0aGUgZmVlZCwgYW5kIGRvZXMgbm90IG93biAnY29uZmxpY3RfZmlsZSc7CiMgICAg J2Zvb18yJyBkZXBlbmRzIG9uICdiYXJfMicuCiMgNC4gcGtnICdiYXJfMicgaXMgYWRkZWQgdG8g dGhlIGZlZWQsIGFuZCBub3cgb3ducyAnY29uZmxpY3RfZmlsZSc7ICdiYXJfMicgY29uZmxpY3Rz IHdpdGggJ2Zvbzw8MicKIyA1LiB1c2VyIGNhbGxzICdvcGtnIHVwZ3JhZGUnIG9yICdvcGtnIGlu c3RhbGwgZm9vJwojCiMgV2hhdCBpcyB0aGUgZXhwZWN0ZWQgb3V0cHV0PyBXaGF0IGRvIHlvdSBz ZWUgaW5zdGVhZD8KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojIEV4 cGVjdGVkOgojICBPcGtnIHNob3VsZCBkZXRlY3QgdGhhdCBgY29uZmxpY3RfZmlsZWAgb3duZXIg c2hpcCBoYXMgYmVlbiBwYXNzZWQgZnJvbQojICAnZm9vJyB0byAnYmFyJyBpbiB0aGUgbmV3IHBh Y2thZ2UgdmVyc2lvbnMsIGFuZCBhbGxvdyB0aGUgdXBncmFkZS4KIyBBY3R1YWw6CiMgIFRoZSBv cGtnIG9wZXJhdGlvbiBmYWlscy4KCgppbXBvcnQgb3MKaW1wb3J0IG9waywgY2ZnLCBvcGtnY2wK aW1wb3J0IHJlCgoKb3BrLnJlZ3Jlc3NfaW5pdCgpCm8gPSBvcGsuT3BrR3JvdXAoKQoKd2l0aCBv cGVuKCdjb25mbGljdF9maWxlJywgJ3cnKSBhcyBmOgogICAgZi53cml0ZSgnVGVzdCcpCgpvbGRf Zm9vID0gb3BrLk9wayhQYWNrYWdlPSdmb28nLCBWZXJzaW9uPScxLjAnLCBEZXBlbmRzPSJiYXIg KD49IDEuMCkiKQpvbGRfZm9vLndyaXRlKGRhdGFfZmlsZXM9Wydjb25mbGljdF9maWxlJ10pCm9s ZF9iYXIgPSBvcGsuT3BrKFBhY2thZ2U9J2JhcicsIFZlcnNpb249JzEuMCcpCm9sZF9iYXIud3Jp dGUoKQoKby5vcGtfbGlzdC5hcHBlbmQob2xkX2ZvbykKby5vcGtfbGlzdC5hcHBlbmQob2xkX2Jh cikKby53cml0ZV9saXN0KCkKb3BrZ2NsLnVwZGF0ZSgpCgpvcGtnY2wuaW5zdGFsbCgnZm9vJykK aWYgbm90IG9wa2djbC5pc19pbnN0YWxsZWQoJ2ZvbycsICcxLjAnKToKICAgIG9way5mYWlsKCJQ YWNrYWdlICdmb28nIGZhaWxlZCB0byBpbnN0YWxsIikKaWYgbm90IG9wa2djbC5pc19pbnN0YWxs ZWQoJ2JhcicsICcxLjAnKToKICAgIG9way5mYWlsKCJQYWNrYWdlICdiYXInIGZhaWxlZCB0byBp bnN0YWxsIikKCgpuZXdfZm9vID0gb3BrLk9wayhQYWNrYWdlPSdmb28nLCBWZXJzaW9uPScyLjAn LCBEZXBlbmRzPSJiYXIgKD49IDIuMCkiKQpuZXdfZm9vLndyaXRlKCkKbmV3X2JhciA9IG9way5P cGsoUGFja2FnZT0nYmFyJywgVmVyc2lvbj0nMi4wJywgQ29uZmxpY3RzPSJmb28gKDw8IDIuMCki KQpuZXdfYmFyLndyaXRlKGRhdGFfZmlsZXM9Wydjb25mbGljdF9maWxlJ10pCgpvLm9wa19saXN0 LmFwcGVuZChuZXdfZm9vKQpvLm9wa19saXN0LmFwcGVuZChuZXdfYmFyKQpvLndyaXRlX2xpc3Qo KQpvcGtnY2wudXBkYXRlKCkKCm9wa2djbC5pbnN0YWxsKCdmb28nKQppZiBub3Qgb3BrZ2NsLmlz X2luc3RhbGxlZCgnZm9vJywgJzIuMCcpOgogICAgb3BrLmZhaWwoIlBhY2thZ2UgJ2ZvbycgZmFp bGVkIHRvIHVwZ3JhZGUiKQppZiBub3Qgb3BrZ2NsLmlzX2luc3RhbGxlZCgnYmFyJywgJzIuMCcp OgogICAgb3BrLmZhaWwoIlBhY2thZ2UgJ2JhcicgZmFpbGVkIHRvIHVwZ3JhZGUiKQo=