My build chroot cannot proceed to upgrade of the system since xf86-input-wacom fails to install because it finds file-collision with linuxwacom. There is a blocker but only one way on linuxwacom side.
Since when do blockers have to be explicitly written on both sides?
The blocker only has to be on one side, but 'retroactive blockers' (added after the package was installed) are not always reliable.
(In reply to comment #2) > The blocker only has to be on one side, but 'retroactive blockers' (added after > the package was installed) are not always reliable. It looks like a case of a retrocactive blocker. You can verify this by checking whether or not /var/db/pkg/x11-drivers/linuxwacom*/*DEPEND contains the blocker. Also, the linuxwacom ebuilds seem to have the blocker in DEPEND, but technically the blockers should go in RDEPEND since otherwise they won't work for binary packages (or even installed packages) since DEPEND has no meaning for packages once they've been built.
(In reply to comment #3) > It looks like a case of a retrocactive blocker. You can verify this by checking > whether or not /var/db/pkg/x11-drivers/linuxwacom*/*DEPEND contains the > blocker. I've added blockers to the xf86-input-wacom ebuilds in order to solve the retroactivity issue. > Also, the linuxwacom ebuilds seem to have the blocker in DEPEND, but > technically the blockers should go in RDEPEND since otherwise they won't work > for binary packages (or even installed packages) since DEPEND has no meaning > for packages once they've been built. I've moved the blockers to RDEPEND.
