[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 #2 from Eric Smith <eric at brouhaha.com> 2010-01-29 05:40:54 EST ---
> you can safely drop the SOlib definitions.

OK

> Does the library *really* have hard-coded paths in the source code? If not,
> then you can drop libdir=%{_libdir} usrlibdir=%{_libdir} exec_prefix=/usr" from
> the make command.

Can't drop them.  The make uses sed to substitute the directory paths into the
.pc file.

> Use %{_prefix} instead of /usr.

OK

> You should own the directory %{_includedir}/bsd/.

OK

> The devel package should Requires: pkgconfig, if you are going to build for
EPEL, modern Fedoras pick up the requirement automatically.    

OK

> If you remove nlist.h, then you should require the package that provides it.
> Are the files really compatible?

This one is tricky.

The functionality of nlist in libbsd is intended to be identical to that in
elfutils-libelf.  To at least a superficial examination, the header seems
functionally identical.  However, I'm not 100% certain that the libbsd
implementation is suitable for Fedora Linux.  Anyone that depends on nlist
should use the one from elfutils-libelf.

Since libbsd is just a collection of random BSD stuff, it seems likely that the
vast majority of libbsd users won't use nlist.  I don't think omitting nlist
makes it appropriate to have the package depend on elfutils-libelf.  Adding
that dependency will not solve the problem even for a libbsd user that does
want nlist, since they would need to add a the elfutils-libelf to their link
anyhow.

The other reason that I don't think omitting nlist from libbsd is going to be a
serious problem for anyone is that the only purpose of libbsd is to support
porting programs from BSD, and anyone doing that will have to change the
#include directives in the program being ported.

What's more of a concern is that if someone does link to both libbsd and
elfutils-libelf, they may get the wrong nlist implementation depending on the
link order.  I think it's best to change the libbsd makefile to not compile or
link nlist, as well as omitting the header.  Unless someone has a serious
objection, I'm going to do that tomorrow and make a new spec and SRPM available
for review.

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