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@xxxxxxxxxxxx> 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review