Status of libbsd include headers

[Guillem Jover]

Hi Eric!

CCing you as I don't think you are subscribed to the list. I've meant
to send this to the list, but taking the opportunity now that you guys
are discussing it in the Fedora bugzilla (for which I don't have an
account anyway).


The current situation with the headers is mostly due to history, and
how the library evolved initially. The ideal solution which I've
already considered would be to make it (optionally) transparent (through
the use of #include_next) so that the ported projects only need to use
pkg-config to get the correct flags, and not get modified.

The problem with this is with compatibility, as it does not work if
existing files do an explicit include with the “<bsd/” prefix, which
would break several of the already ported packages at least in Debian.
This would need a transition plan drafted and followed through. Also
currently at least <bsd/sys/queue.h> will clash with definitions from
<sys/queue.h>, that could be fixed though.


But probably the best solution might be to expose the headers to be
explicitly used under /usr/include, and the transparent ones under a
directory under /usr/lib/libbsd/ or /usr/share/libbsd/, in a similar
way as how gcc ships fixed headers. This would avoid the compatibility
problem, and a new .pc file could be shipped, something like
libbsd-transparent.pc or similar.


The current usage which minimizes changes is to use “-include bsd/bsd.h”
in CFLAGS, but it might pollute the namespace if the application did not
expect those symbols to appear. I should probably write down the usage
possibilities in a porting file in the source tree.


Regarding specific headers, yes, <nlist.h> is a problem we also have in
Debian (OTOH the implementation in libbsd supports a.out but I guess
that's not much of a selling point these days :), I'd recommend not
shipping it at all in the RPM package, but do not simply remove the
function from the shared library as that'd change the ABI, it will be
removed on the next SOVERSION bump. I'll probably stop shipping it in
Debian too, but there I'll have to handle a transition, as making
libbsd-dev start Depending on libelf-dev is not enough, the application
will need to start linking against the libelf shared library too.

Additionally there should be no link problem regarding nlist as libbsd
uses versioned symbols, and I think the libelf implementation used in
Fedora does too.

You could also avoid shipping the deprecated headers, so that you skip
possible future transitions of people using them, although with the
warnings in place that should not be a problem. I might add a make
target to only install non-deprecated headers.

thanks,
guillem