On 2018-04-20 01:24 +0200, Guillem Jover wrote: > On Tue, 2018-04-03 at 12:39:54 +0100, Colin Watson wrote: >> Control: reassign -1 libedit-dev 3.1-20170329-1 >> >> On Sat, Mar 24, 2018 at 02:37:57AM +0100, Guillem Jover wrote: >> > I just noticed that the latest version of this package depends on >> > libbsd0, which at first thought it was nice given my previous bug >> > request :), but then realized it was probably unintended when I >> > checked the actual sources. Here's the reasons why: >> > >> > * Build-Depends on libedit-dev, which pulls in libbsd-dev. >> > * configure.ac uses AC_CHECK_LIB instead of AC_SEARCH_LIBS to >> > check for daemon(), which detects daemon() from glibc and >> > concludes that libsd is needed. > >> Nope. The check you mention is in the false branch of an >> AC_CHECK_FUNC([daemon], ...), so isn't run because we detect glibc's >> version first. > > Argh! Sorry, you are right, should have stared at the code a bit > longer. :) > >> The actual reason is: >> >> $ pkg-config --libs libedit >> -ledit -lncurses -lbsd >> >> Maybe -lbsd should be moved to Libs.private? But I don't know the >> libedit interface in detail, and in any case this is up to the libedit >> maintainers, so reassigning. > > I think so, yes. This seems like an actual regression from upstream, > because the patch to switch it to use libbsd which I sent and got > carried for a while in Debian was using Requires.private.
In version 3.1-20180525 -lbsd (and -lncurses) was moved back to Libs.private, and openssh-client no longer depends on libbsd0 when I rebuild it. However, is linking libedit with -lbsd necessary at all on a recent glibc version? At least dpkg-shlibdeps warns that libedit does not use any of libbsd's symbols. Cheers, Sven