Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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.
Comment by Dave Reisner (falconindy) - Saturday, 17 August 2013, 19:49 GMT
-1 to this idea. The dependency is real. The debug package is useless without the same binary package which it was generated from (this goes for pkgrel, not just pkgver).

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.
Comment by Yaohan Chen (hagabaka) - Saturday, 17 August 2013, 19:58 GMT
The debug package has no use other than providing symbols *for* the binary package. The binary package's debugging functionality depends on the debug package, not the reverse.

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.
Comment by Dave Reisner (falconindy) - Saturday, 17 August 2013, 20:16 GMT
> The binary package's debugging functionality depends on the debug package, not the reverse.
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.

Loading...