[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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!

Hi Guillem and Andrej,

Thanks for your interest in this!

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 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.

It may also be of interest that FreeBSD recently imported NetBSD's mtree
into their contrib tree, and switched their default mtree to NetBSD's.
They still have the FreeBSD mtree (named fmtree, dovetailing nicely with
freebsd-buildutils).  I examined it for packaging instead of the one
from the NetBSD tree.  They don't use nbcompat, and ripped all of the
things from nbcompat.h out (adding many #includes to their .c files,
making FreeBSD-specific assumptions, etc.)  They pulled out autoconf
entirely.  Basically, theirs is less portable, won't trivially track the
NetBSD source, and will likely require more work to maintain over the
long term.

-- John


Reply to: