| Summary: | opkg incorrectly fails to upgrade packages when an owned file has been transferred to a dependency. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Yocto Project Subprojects] opkg | Reporter: | Alex Stewart <alex.stewart> | ||||
| Component: | opkg | Assignee: | Alex Stewart <alex.stewart> | ||||
| Status: | ACCEPTED --- | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Undecided | CC: | dylan.turner | ||||
| Version: | 0.4.5 | ||||||
| Target Milestone: | next-minor | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
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 |
Created attachment 4843 [details] 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.