I've made an attachment because I've got a lot of output.
Created attachment 98473 [details] output for various commands, etc
Comment on attachment 98473 [details] output for various commands, etc don't attach stuff as binary
I think this could make a problem when gen-2 goes stable and people start upgrading their packages... Not sure what to do about it, maybe have new ant-core block old ant-tasks? Yeah blockers confuse people and they go filling bugs and ask on IRC/forums but there's already a blocker for java-config vs java-config-wrapper in the upgrade path, so one more wouldn't hurt maybe?
(In reply to comment #3) > I think this could make a problem when gen-2 goes stable and people start > upgrading their packages... Not sure what to do about it, maybe have new > ant-core block old ant-tasks? People are filing invalid bugs about mismatched -core and -tasks all the time, blockers are still better than leaving this broken. Alternatively, ebuilds should depend just on dev-java/ant metabuild instead of depending directly on ant-core/ant-tasks?
I don't think the bug reports are invalid unless users have keyword inconsistencies, like ant-core ~arch and ant-tasks or ant arch. But even with good keywords you can run into problems if portage issues something between ant-core and ant-tasks update (which can also cause upgrade/downgrade loops and other fun stuff). Making everything depend on ant is against the idea of having it splitted (because ant-tasks have many and some even fetch restricted deps etc, and you can't build those deps without having ant-core first). Soon even ant-tasks will get splitted, but don't worry, I'm doing it so it won't try to load mismatched versions. For the time being, blocker sounds best... Nichoj?
Yes, we should go with the blocker until we have the totally modular ant-tasks.
The block "!<dev-java/ant-tasks-${PV}" was already present in ant-core-1.6.5-r2, I've added it to -r14 too.