FS#36578 - [makepkg] Do not let -debug packages depend on their regular packages
Attached to Project:
Pacman
Opened by Yaohan Chen (hagabaka) - Saturday, 17 August 2013, 19:42 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 17 August 2013, 19:58 GMT
Opened by Yaohan Chen (hagabaka) - Saturday, 17 August 2013, 19:42 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 17 August 2013, 19:58 GMT
|
Details
Description:
makepkg can be configured to produce -debug packages containing only the debug symbols. These packages depend on their regular packages, e.g. foo-debug-1.0 depends on foo-debug=1.0, but they shouldn't. There is no actual dependency: The debug packages don't require their regular packages to function. They only add improved debugging functionality to the regular packages. It is more appropriate to have foo-1.0 optionally depend on foo-debug=1.0, but since debug packages are not provided in the repositories, the optdepend isn't very useful either. Having the dependency causes pain for users: When upgrading a package foo from 1.0 to 1.1 with foo-debug-1.0 installed, pacman will complain about unresolved dependency, and the user has to manually remove foo-debug first. Reasons for having the dependency are not good enough: After upgrading foo from 1.0 to 1.1, foo-debug-1.0 probably becomes useless, so maybe the unresolved conflict error serves as a way to remind the user to remove it. But this is not consistent with the way similar situations are handled. If foo-1.0 depends on libbar, and foo-1.1 does not depend on libbar, libbar becomes useless. But this is usually handled by installing libbar --asdeps, and not by having libbar depend on foo=1.0. After upgrading foo from 1.0 to 1.1, the symbols in foo-debug-1.0 may become incorrect, and it can be argued that having the wrong debug package installed is worse than having no debug package installed. I haven't really tried this so I don't know how much worse it is, or if gdb is able to figure out the symbols file is wrong and not use it. But I think this is similar to -docs packages: linux-docs is specific to the same version of linux, but it doesn't depend on linux, and similar for other -docs packages. Usually a system upgrade will upgrade linux-docs at the same time as linux, but if the user specifically upgrades only linux and linux-docs, the docs will be out-of-date, but this doesn't really affect the functionality of the packages. If the user plans to debug foo-1.1, they should also install foo-debug-1.1, and if not, then having foo-debug-1.0 installed is harmless. |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 17 August 2013, 19:58 GMT
Reason for closing: Won't fix
Additional comments about closing: The dependency is legitimate. If you don't want to rebuild the debug package with subsequent versions, then you need to uninstall it.
Saturday, 17 August 2013, 19:58 GMT
Reason for closing: Won't fix
Additional comments about closing: The dependency is legitimate. If you don't want to rebuild the debug package with subsequent versions, then you need to uninstall it.
Comparing this to -docs packages is silly. Documentation *might* be 100% relevant between versions or it could be 0% relevant. debug packages are guaranteed to be 0% relevant for new versions.
If only non-binary content of a package is updated, isn't it still possible for a debug package to be compatible with a new version? Though I think whether this is true is irrelevant in the first place.
The debug symbols depend on the binary package. I haven't seen a compelling argument to disprove this yet.
> If only non-binary content of a package is updated, isn't it still possible for a debug package to be compatible with a new version?
Only if the build-id remains the same.