It's in /lib, not /usr/lib...

Bumping the version and breaking packages (hassling users) for this doesn't seem warranted. The move itself is an opinion that we would be copying.

If I don't bump the version, then there are 2 copies of the function floating around -- one in libc, the other in libutil. Why bloat libutil like that?

Let me step back a bit and try to explain the justification for the change..

fparseln on FreeBSD requires stdio.h and libutil.h / libutil.so.
fparseln on NetBSD requires stdio.h.

Trying to reduce the diff in contrib/netbsd-tests, I was again reminded of why I polluted tests that use fparseln 2 years ago... hexdump in contrib/netbsd-tests/lib/libc/hash/h_hash.c conflicts with hexdump(3) in libutil. I tried quickly adapting h_hash.c to hexdump(3), but in order to make it work, I'd have to add additional flags to support the output, and even then it wasn't working 100% because of how hexdump in h_hash.c handles string lengths vs hexdump(3) in libutil. Given that fparseln came from NetBSD in the first place, it seems a lot more fitting to follow their lead and move it to libc -- especially because it reduces unnecessary convolution in libutil.h (note that libutil.h exposes fparseln if and only if stdio.h is first included).

I guess this is my "brilliant idea" in trying to get things to work in a way that makes the most sense instead of continuing to hack contrib/netbsd-tests for FreeBSD where it doesn't make sense.

Yes, I just think the cost should be weighed of maintaining *3* patches in contrib/netbsd-tests vs package grief and an API change for an obscure function. POLA comes to mind as it will make upgrading packages needing libutil painful. I had never heard of this function before. If we're going to do things that bump a version I'd rather see more bundled into the bump to make it worth the cost. There are other functions in libutil that may make more sense in libc. A public discussion on arch@ would be better about this I think. Though, we're 15 years past their move and I don't see a pressing need for it right now when we can just work around it.

This would need to be updated to use libc instead of libutil.

Going to hold off on this until I get an idea of whether or not people want to move forward with this overall proposed change.

It won't really be any more difficult -- it's just that libutil after this change will be a superfluous requirement for things that need fparseln.