[Bug 559856] Review Request: libbsd - Library providing BSD-compatible functions for portability

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=559856

--- Comment #6 from Eric Smith <eric at brouhaha.com> 2010-01-30 04:36:11 EST ---
Regarding /usr/include/vis.h "adding a bsd-header to glibc", I strongly
disagree.  There is no general concept that headers in /usr/include belong to
glibc.  On my build system, there are 304 headers in /usr/include (not counting
subdirectories), of which 109 are owned by glibc-headers, and 197 are owned by
non-glibc packages.

Aside from nlist,.h which I've moved, and vis.h which you mentioned, libbsd has
one other header in /usr/include, libutil.h.  Neither vis.h nor libutil.h
conflict with any other Fedora package.

Regarding /usr/include/libbsd, I understand what you suggested, but I disagree
about the location.  libbsd installs most of its headers in /usr/include/bsd,
which exist in any other Fedora package.  gcc reports that its default search
path does not include /usr/include/bsd.  Since the purpose is portability, I
don't see any reason why moving those headers to /usr/include/libbsd is an
improvement.  In the case of nlist, which they installed as
/usr/include/nlist.h, I've agreed to move it to /usr/include/bsd/nlist.h, which
shouldn't be a problem for programs being ported since they should just use
elfutils-libelf for that anyhow.

Reading your comments I almost get the impression that you think libbsd is
intended to be a general-purpose library that should eventually be relied on by
newly written software and many Fedora packages, and nothing could be further
from the truth.  The point is merely to make it easier to build BSD-centric
software for Fedora, without adding entirely new ad-hoc implementations of some
of those functions into each such package, and having to maintain each of
those.  For instance, I could certainly write a strlcpy() function of my own to
include in another package I'm porting from BSD, or I could patch the upstream
source to not use strlcpy(), but in either case I am likely making the software
LESS reliable by adding unproven code, and making them require MORE work to
maintain in Fedora.

Anyhow, while I'm perfectly willing to discuss the implications, at the end of
the day I'm looking for a review that determines whether the package meets the
Fedora packaging guidelines, not whether it is the finest, most elegant example
of software engineering, nor whether strlcpy() and friends are good, bad, or
ugly.  The reality is that there are some packages out there written
specifically for BSD, and it is useful to have a library that makes it easier
to port them.  No, libbsd doesn't solve all BSD portability problems, nor does
it claim to.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.