On 2016-04-02 14:19 +0200, Axel Beckert wrote:
> Hi Sven,
>
> Sven Joachim wrote:
>> > If libncurses5-dev is installed on the build system, screen is linked
>> > with -lcurses rather than -ltermcap or -ltinfo, giving an extraneous
>> > dependency on libncurses5. This is because configure checks for
>> > -lcurses before trying -ltermcap or anything else.
>>
>> I've seen that you added a Build-Conflicts with libncurses5-dev which is
>> rather suboptimal, since it prevents building screen in anything but the
>> most basic chroot.
>
> Which is completely fine for me. pbuilder is easy to setup and use.
> And yes, it means that I have to do every build in pbuilder, too.
> Doesn't hurt, though. Did it many times in the last hours.
I'm using pbuilder as well, but it's not so great when you need to
inspect the build tree afterwards since pdebuild deletes the build
chroot by default.
>> Moreover, it's going to introduce an FTBFS after the Jessie release
>> when libncurses5-dev and libncursesw5-dev are likely going to depend
>> on the same package.
>
> I'm sorry, but I can't follow this argument for multiple reasons:
>
> * We're already a year after the Jessie release and it still builds.
> Maybe you meant Stretch instead of Jessie?
Yes, sorry.
> * If I conflict with libncurses5-dev and depend on libncursesw5-dev
> and both depend on the same package, that won't hurt. Actually, they
> already do: libtinfo-dev and libtinfo5.
Right, what I meant is that libncurses5-dev and libncursesw5-dev will
also be _provided_ by the same package. The exact layout of the new
ncurses packages fixing bug #230990 is not clear yet, but I guess we
will have a libncurses-dev package providing both libncurses5-dev and
libncursesw5-dev. For users' convenience there also need to be
transitional packages, but those may be dropped after the Buster
(Stretch+1) release.
>> The right way to fix this bug is to change configure.ac to try -ltinfo
>> first, see the attached patch which can be dropped into debian/series
>
> Ok, that patch is small enough to be acceptable as an alternative to
> the build conflict.
>
>> diff --git a/configure.ac b/configure.ac
>> index ffe2e37..ccebe56 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -657,6 +657,9 @@ dnl
>> AC_CHECKING(for tgetent)
>> AC_TRY_LINK(,tgetent((char *)0, (char *)0);,,
>> olibs="$LIBS"
>> +LIBS="-ltinfo $olibs"
>> +AC_CHECKING(libtinfo)
>> +AC_TRY_LINK(,tgetent((char *)0, (char *)0);,,
>> LIBS="-lcurses $olibs"
>> AC_CHECKING(libcurses)
>> AC_TRY_LINK(,[
>> @@ -681,9 +684,6 @@ AC_TRY_LINK(,tgetent((char *)0, (char *)0);,,
>> LIBS="-lncurses $olibs"
>> AC_CHECKING(libncurses)
>> AC_TRY_LINK(,tgetent((char *)0, (char *)0);,,
>> -LIBS="-ltinfo $olibs"
>> -AC_CHECKING(libtinfo)
>> -AC_TRY_LINK(,tgetent((char *)0, (char *)0);,,
>> AC_MSG_ERROR(!!! no tgetent - no screen)))))))))
> ^^^^^^^^^^^^^^^^^^^^^^
>
> Shouldn't that last line moved with the other lines, too?
I don't think so, the AC_MSG_ERROR line is for the case where all of the
attempts to find tgetent in libtinfo, libcurses, libtermcap etc. failed.
Cheers,
Sven
