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

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

Closed by  Allan McRae (Allan)
Sunday, 04 August 2019, 23:03 GMT
Reason for closing:  Not a bug
Comment by Allan McRae (Allan) - Sunday, 04 August 2019, 05:51 GMT
Is /usr/bin/vim in the gvim package a symlink?
Comment by lilydjwg (lilydjwg) - Sunday, 04 August 2019, 07:07 GMT
No, gvim (and others) are symlinks to vim (and it's a different Vim than the other package). I build twice, once with GUI support and once without, and then I get two /usr/bin/vim that conflicts with each other. (The common files are packaged in another vim-runtime package.)

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.
Comment by Allan McRae (Allan) - Sunday, 04 August 2019, 07:21 GMT
Two ./configure and make sections means this should be two PKGBUILDs. I consider this an example of poor packaging and not a configuration that makepkg should support.
Comment by lilydjwg (lilydjwg) - Sunday, 04 August 2019, 08:13 GMT
It's how Arch handles packages based on the same source. Split packages are used to handle the following issues:

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.
Comment by Bartłomiej Piotrowski (Barthalion) - Sunday, 04 August 2019, 14:12 GMT
Re-opening, as this is an actual issue. Unless Allan suggests our tooling is actively fighting package maintainers, but then I don't see why we should have an Arch Linux fork of pacman to fix what actually bothers packagers.
Comment by Doug Newgard (Scimmia) - Sunday, 04 August 2019, 15:21 GMT
Threatening to fork pacman because you want to use a hacky solution to get around basic PKGBUILD organization? What?
Comment by Bartłomiej Piotrowski (Barthalion) - Sunday, 04 August 2019, 17:52 GMT
Hacky solution as in one that reduces workload on people? Weird priorities.
Comment by Eli Schwartz (eschwartz) - Sunday, 04 August 2019, 19:02 GMT
In this case, installing gvim as gvim, not a symlink to a vim which is built differently (and instead leaving vim to be the symlink to gvim), is all that is needed. I haven't fully examined all use cases, but this example doesn't count.

In other words,  FS#63357  was prematurely closed as it's entirely feasible to make extra/vim (the split package) work fine today.
Comment by Bartłomiej Piotrowski (Barthalion) - Sunday, 04 August 2019, 20:14 GMT
There are at least bubblewrap, qemu and quassel providing variants conflicting each other.
Comment by Eli Schwartz (eschwartz) - Sunday, 04 August 2019, 20:30 GMT
Bubblewrap doesn't count either, since it builds the exact same code with the exact same options and produces byte-identical binaries with byte-identical debug build-ids and debug symbols, but does it twice in order to use a Makefile in the second case that runs an install-exec-hook which executes chmod u+s "${pkgdir}"/usr/bin/bwrap
(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...
Comment by Allan McRae (Allan) - Sunday, 04 August 2019, 23:03 GMT
Different code producing binaries of the same name in the same PKGBUILD is bad packaging and will not be supported.

Loading...