Re: BUG #17358: While using --with-uuid=bsd option, uuid_ossp test fails on NetBSD 9.2

Andres Freund <andres@anarazel.de> writes:
> On 2022-01-08 14:59:56 -0500, Tom Lane wrote:
>> Right, I was planning to have a look at how they'd done it.  The BSD
>> implementation seems to be inside the kernel, so that's not likely
>> to be helpful, but the other two must be in userspace.

> https://github.com/tytso/e2fsprogs/blob/master/lib/uuid/gen_uuid.c#L240
> https://github.com/sean-/ossp-uuid/blob/master/uuid_mac.c#L92

Thanks for the pointers!  I was hoping for a Windows version, but
neither one seems to cover that.  OTOH, that means that we can't
build uuid-ossp on Windows today anyway, so failing to support it
makes things no worse than before ... and anybody who wants that
can always send a patch.

Before I start writing code, there seem to be two possible approaches
here:

1. Rip out all the external-library dependencies, lock stock and
barrel.  contrib/uuid-ossp is always built.  --with-uuid configure
argument becomes a no-op or an error.

2. contrib/uuid-ossp is always built, but if you say --with-uuid
then the existing code for that library is used.  We fall back to
homegrown code if you didn't say --with-uuid.

The main argument for #2 would be to preserve bug compatibility with
the existing behavior, in case (say) we pick a different interface's
MAC address than you got before.  I suppose also it's possible that
the existing libraries try harder to avoid collisions across UUIDs
generated in different processes than I envision doing in our own
version.  (I think v1 UUID uniqueness is snake-oil anyway, so I'm
just thinking of choosing a random "clock sequence" in each process
and calling it good.)

Whether these are good enough reasons to continue carrying all
that code is unclear to me.  Thoughts?

			regards, tom lane