On Thu, Jan 31, 2013 at 10:22:44PM -0600, Mark Linimon wrote: > On Thu, Jan 17, 2013 at 09:15:02AM -0600, Brooks Davis wrote: > > Not unless you consider adding new functions in a reserved namespace > > (str*) to be ABI breakage. > > Well, what often happens is that when we add new functions, ports break. > I think deciding whether this is or is not "ABI breakage" is semantics. > The fact is that regressions get introduced with these types of changes. > > > The port should have continued to work unless it was recompiled so it > > should have preferred it's own version of the strnvis symbol. If its > > makefiles were properly constructed it would have failed to compile > > due to the signature mismatch. > > The mantra should be "every possible combination of ways that a port's > internal build glue can be wrong, is already included in the Ports > Collection." > In case after case we see fragile code that is written by people who are > clearly not professionally trained. They "get it to work on their system" > and then shove it out the door. > > Claiming that "they shouldn't do that" is correct but self-defeating. > It's just the reality of open-source software.
I'm not sure why I'm being jumped on me in this weeks old report of a now-fixed problem. I did determine to root cause and others produced a patch. If no one else had stepped up I would have done so my self. > IMHO, the burden should be on whoever makes the change to find out whether > or not regressions will be introduced. (And yes, I am very aware that we > don't have -exp run capability right now, but this is one of the cases > where I would like to suggest it would have helped.) I would likely have done an exp run had there been the capability of doing one, but this bug would not have been found since it's a runtime crash caused by a combination of two different BSD projects not talking to each other and poorly chosen CFLAGS in the upstream software allowing it to compile. One could probably write a tool to detect some forms this sort of issue (even premptively), but it's probably not worth doing. -- Brooks
pgpSXZsGprvjG.pgp
Description: PGP signature