It appears that both ebuilds produce: /usr/bin/mtest /usr/bin/mailutil /usr/share/man/man1/mailutil.1.gz Reproducible: Always Steps to Reproduce:
Hm, correct. I wonder how to resolve this - maybe checking if the other package is installed and do not install these three files in that case? This in both pine and uw-imap, of course. Another option would be to rename one instance, f.e. mailutil-pine, mtest-pine, but that's probably not a good idea, since the package might call these two binaries directly.
Neither way is a GoodThing(tm), I guess I'll just put mailutil into a separate package, just as OpenBSD does it.
Looks like all UW mail software has a delicate build system, it will not be trivial to pry mailutil/mtest out of there as a separate package.
why don't you just set DEPEND= !mail-client/pine in uw-imap and vice versa? that's what blocks are for
Because it's entirely reasonable to want both uw-imap and pine installed on the same system. Debian, for instance, has three separate packages: uw-imap, pine, uw-mailutils (the latter also built from the uw-imap source).
To add to the previous comment -- if I want BOTH pine and the uw POP and IMAP servers, exactly how do I accomplish this? Actually, just to show what a mess the dependencies are today, it is entirely possible today, if one gets the right order: 1. uw-mailutils 2. pine 3. uw-imap Done in this order, there are no dependency blockages. But that is hardly the point. I should not be able to work either around the dependencies, but I should be able to install the Pine email client AND the UW POP and IMAP servers without having to worry about the order.
This is the issue I'm trying to fix in bug #108647 - uw-imap and uw-mailutils went into stable early due to security bug #108206, but pine didn't. Currently, only hppa arch hasn't stabilized pine-4.64-r1, rest of the arches should just wait for their mirrors to sync with main portage mirror, and all will be fine. Of course, if you're upgrading from lower version of pine or uw-imap, you'll need to unmerge the old version first. Sorry about that, but it's a better solution than not putting in those blocks and having the emerge process bail out in the middle of a batch upgrade, on a collision-protect warning.
pine and uw-imap are written by the same persons and these packages share a lot of common source code, it is possible that there is no conflict and these commands are identical
Closing this bug, as pine-4.64-r1 has been stablilized for all arches long time ago.