FS#63356 - debug packages is broken for conflicting split packages
Attached to Project:
Pacman
Opened by lilydjwg (lilydjwg) - Sunday, 04 August 2019, 04:38 GMT
Last edited by Allan McRae (Allan) - Sunday, 04 August 2019, 23:03 GMT
Opened by lilydjwg (lilydjwg) - Sunday, 04 August 2019, 04:38 GMT
Last edited by Allan McRae (Allan) - Sunday, 04 August 2019, 23:03 GMT
|
Details
Summary and Info:
Now makepkg creates a single debug package for split packages. The issue is, when split packages conflict, the conflicting file is overwritten. Steps to Reproduce: I build my own Vim, splitting as three packages: vim, gvim and vim-runtime, as you may expect. Both vim and gvim packages contain a binary called "vim", and I get only one "/usr/lib/debug/usr/bin/vim.debug" file. The debug package for one of the splitted packges is broken. |
This task depends upon
The PKGBUILD I use was based on the official Arch one and produces similar packages (except that I didn't sync for some time). I expect similar issues with the official Arch one if it would enable debug packages.
1. same source
2. common, shared files
I've seen lots of official packages written in this way (e.g. most Python packages). Copy source, build twice, produce two or three (if there are common files) packages. Besides vim, there is also the iptables that splits into conflicts packages (well, this one only builds once).
If building twice is poor packaging, then there are lots of poor packaging packages in the official repo, and I'd like to wait for them to be fixed so that I can learn and adapt to better packaging.
In other words,
FS#63357was prematurely closed as it's entirely feasible to make extra/vim (the split package) work fine today.(We can be thankful, therefore, that the package supports reproducible builds.)
I dunno about "poor" packaging, but it's certainly a waste of CPU cycles to run the compiler twice and generate identical output. Granted that the package does not take very long to build either way.
The other two packages do seem to be generating different code under the same binary names...