Still no traceback for ports conflicts during "pkg upgrade"

[John Marino]

On 12/29/2013 22:08, Beeblebrox wrote:
> I am getting several ports conflicts when doing a "pkg upgrade". The most
> obvious example is lang/gcc vs lang/gcc46:
> pkg: WARNING: locally installed gcc-4.6.4 conflicts on
> /usr/local/lib/gcc46/include/c++/x86_64-portbld-freebsd11.0/bits/error_constants.h
> with:  - gcc46-4.6.4_1,1
> 
> As I had requested previously, "There needs to be an -x (exclude) flag or
> better yet a traceback method for pkg upgrade" so that one can trace the
> port causing the issue.  lang/gcc46 is not the only port causing such
> problem.

As I read the warning, the problem is that you have gcc4-6 installed
from outside ports, so lang/gcc46 isn't the problem, but rather the fact
you "locally installed gcc-4.6.4"

So let me get this straight:
1) You previously requested a pkgng feature that apparently you didn't
get feedback on whether it was even a good idea or not...
2) You waited some time
3) You post this message with title starting "Still not traceback for
ports" noting that it had been previously requested

So I'm inferring that you expect your previous request was sufficient
justification for the feature, and now you are annoyed that nobody spent
their volunteer time implementing it yet in a time period you deemed
sufficient?

that provokes some questions
1) Where was this discussed ending with the conclusion that this feature
should be in place?
2) Which PR issue number is this request?
https://github.com/freebsd/pkg/issues
3) Have you attempted either providing patches or offering bounties for
the feature?

> I admit that one of the possible causes could be that I marcusmerge the
> gnome3 ports. However, this does not make my request any less sensible,
> since there will probably be many other development branches in the future.

What if the conclusion that running merged trees is outside of the
normal operations comes?  I'd call this "use at your own risk" myself.
The normal sanity checks over the entire tree don't cover these dev
branches AFAIK.  So if others agree this is not a supported use case,
then that does affect the sensibility of the request.  Is it stated
anywhere that dev branches need to be supported by all the other
committers and building infrastructure?  Personally that would stretch
me too then and I don't think I'll pay any attention whatsoever to a dev
branch.

John