Bug#910252: ITP: libnbcompat -- NetBSD compatibility library

[Guillem Jover <guillem@debian.org>]

Hi!

On Thu, 2018-10-04 at 08:28:57 -0500, John Goerzen wrote:
> On Thu, Oct 04 2018, Guillem Jover wrote:
> > Hmm, what does this library provide that is required by mtree-netbsd not
> > available in glibc, libbsd and libmd? Perhaps even freebsd-glue?
> >
> > I've skimmed over the functionality and it seems most of it is already
> > covered by those. If there's still stuff needed I'm always happy to add
> > it to libbsd or libmd as required!

> You are correct that the functionality is generally available.  The
> problem is that the interfaces are different.  nbconfig.h, for instance,
> defines a number of HAVE_* macros that are used while building mtree.
> nbconfig.h includes a number of system header files (stdio.h, etc.) that
> cause *numerous* build errors if missing.  There are also functions for
> things like hashing files that take different numbers of parameters,
> etc.

I see the packages have already gone through NEW, so I've taken a
look. And I've almost got mtree-netbsd building using just libmd and
libbsd. I'll be releasing new upstream versions fixing or adding the
missing stuff:

  - libmd had bogus compat macros for SHA512, and missing ones for
    SHA384.
  - libbsd is missing the pwcache modules from the BSDs, which I'll
    be adding.
  - libbsd is missing a <time.h> that implicitly includes
    <sys/time.h>, I'll be adding that.

Then I've got some minimal patches for mtree-netbsd, which fix or improve
things there, that I'll be sending your way once I've finished with the
above. At which point I think it would be nice to drop libnbcompat
completely?

The point of creating libmd and libbsd and switching projects to use
those, was to have such BSD compatibility library in a single place
which can be fixed centrallly, and to reduce embedded code copies. So
adding yet similar library would make the situation confusing and
might distract from such unifiying efforts. :)

> I also considered, for a bit, whether to even make libnbcompat be a
> separate package.  I concluded yes, because:
> 
> 1) It has its own standalone configure,
> 
> 2) It must be configured and built before mtree can be configured,
> 
> 3) Even on NetBSD, mtree requires libnbcompat to build (the #include
> <nbcompat.h> is not wrapped inside any conditional macro)
> 
> Because of #1 and #2, just including it in mtree itself would cause the
> build system to somewhat violate the usual principles of how to build.

I really think libnbcompat should be completely unnecessary. :) And if
there'd be new features required my mtree-netbsd in the future I'm
always happy to consider new additions to these libraries if they make
sense!

Thanks,
Guillem