Hi! On Thu, 2013-09-05 at 19:52:13 +0200, Michael Biebl wrote: > Am 05.09.2013 19:42, schrieb Julien Cristau: > > On Thu, Sep 5, 2013 at 19:40:18 +0200, Michael Biebl wrote: > >> Am 05.09.2013 19:29, schrieb Julien Cristau: > >>> On Thu, Sep 5, 2013 at 17:50:18 +0200, Michael Biebl wrote: > >>>> Am 05.09.2013 17:29, schrieb Robert Millan: > >>>>> -#include <nlist.h> > >>>>> +#include <bsd/nlist.h>
Please try to avoid this, which cannot be easily upstreamed, or if it can be upstreamed it unnecessarily pollutes the source. > >>>> Does that also work with FreeBSD so can be pushed upstream? > >>>> Apparently libgtop2 has native FreeBSD support and I wonder if nslist.h > >>>> is using a different location on FreeBSD. > >>>> > >>> In xorg-server added `pkg-config --cflags libbsd-overlay` to CPPFLAGS > >>> from debian/rules. Lets the code expecting bsd headers on bsd work > >>> without patching. Yes, that's the ideal solution, which generally avoids any patching. > >> That's confusing tbh. Why is libbsd-dev using different paths in the > >> first place which requires such hacks? > >> > > Because the normal bsd paths would conflict with gnu libc-dev headers > > (maybe not for nlist.h, but for others). > > Why do libc-dev and libbsd-dev have conflicting files in the first place > and why not move just the conflicting (BSD) files to bsd/ ? Most header files provided by libbsd-dev are overlays over the libc ones. For example strlcpy() and friends in bsd/string.h, or slightly different implementations like bsd/sys/queue.h. Then there's partial implementations like bsd/libutil.h which does not conflict with anything, but exposing it directly under /usr/include can confuse software that might assume functionality in libc just because the file is there, for example I think perl suffered from this in Debian at some point. And there's files already shipped by other pre-existing libraries, like bsd/nlist.h, provided by libelfg0-dev and libelf-dev. And no, Replaces does not cut it, because once you remove libbsd-dev then the other libraries will be missing the header. This was a mistake I corrected by namespacing it under bsd/ (the aforementioned link on the list). After all these cases, the only remaining non-conflicting headers are readpassphrase.h, vis.h and md5.h. For md5.h taking over the global namespace seems wrong (it probably belongs in the to-be-uploaded libmd), at which point having the remaining two namespaced seems safer, more future-proof and nicer to other projects. > Apparently libgtop2 built just fine in the past with libbsd-dev, so this > looks like a recent regression in that package. I went over any package explicitly declaring a Build-Depends on libbsd-dev when I did those changes, if libgtop2 is directly using stuff from libbsd-dev but not declaring it explicitly, that's hardly my fault? :) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
