Recently the readline-dev package and its GPL2 variant
libreadline-gplv2-dev dropped their dependencies on libncurses5-dev.
This prompted me to look for packages that currently depend on
libncurses5 but do not build-depend on libncurses5-dev or its aliases
libncurses-dev and ncurses-dev, nor have libncurses5-dev pulled in via
other means.

In the end I found 58 such packages on i386 in unstable/experimental,
all but two of which build-depend on one of the libreadline*-dev
packages. Since those are potentially RC-buggy, they probably deserve a
look. The two exceptions are afflib (bug #645915) and
nvidia-cuda-toolkit (non-free, binary-only(?)).

List of source packages:
acedb
afflib
atari800
atftp
bacula
bc
cdcd
chrony
ctsim
cyphesis-cpp
dbacl
ddd
dump
dvbstreamer
eresi
eukleides
evolver
fityk
gcl
gftp
ginac
glusterfs
gnokii
gnu-smalltalk
gnudatalanguage
gutenprint
haskell-readline
honeyd
illuminator
inetutils
ipmitool
lftp
libphysfs
lie
lua5.2
lustre
malaga
mono-debugger
multipath-tools
nickle
nvidia-cuda-toolkit
pyxplot
qcake
samba
scanmem
spectemu
sqlite
sqlite3
tclreadline
torque
twinkle
udftools
uml-utilities
units
xqf
yap
yaz
zeroc-ice


dd-list:

"Adam C. Powell
illuminator (U)

Laszlo Boszormenyi (GCS) <gcs@debian.hu>
sqlite
sqlite3

Clint Adams <clint@debian.org>
haskell-readline (U)

Matthias Albert <matthias@linux4experts.de>
glusterfs (U)

Russ Allbery <rra@debian.org>
nvidia-cuda-toolkit (U)

Richard Atterer <atterer@debian.org>
udftools

Juan A. Añel <aetherlux@gulo.org>
gnudatalanguage (U)

Mirco Bauer <meebey@debian.org>
mono-debugger (U)

Axel Beckert <abe@debian.org>
gnudatalanguage (U)

Andreas Beckmann <debian@abeckmann.de>
nvidia-cuda-toolkit (U)

Dominique Belhachemi <domibel@debian.org>
torque (U)

John V. Belmonte <jbelmonte@debian.org>
lua5.2 (U)

Luk Claes <luk@debian.org>
ipmitool (U)

Leo Costela <costela@debian.org>
gnokii

Vincent Danjean <vdanjean@debian.org>
yaz

Debian Bacula packaging Group <pkg-bacula-devel@lists.alioth.debian.org>
bacula

Debian Forensics <forensics-devel@lists.alioth.debian.org>
afflib

Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
libphysfs

Debian GNU Smalltalk maintainers <pkg-gnu-smalltalk-devel@lists.alioth.debian.org>
gnu-smalltalk

Debian Haskell Group <pkg-haskell-maintainers@lists.alioth.debian.org>
haskell-readline

Debian Lustre Packaging team <pkg-lustre-maintainers@lists.alioth.debian.org>
lustre

Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>
multipath-tools

Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org>
acedb

Debian Mono Group <pkg-mono-group@lists.alioth.debian.org>
mono-debugger

Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>
nvidia-cuda-toolkit

Debian Printing Group <debian-printing@lists.debian.org>
gutenprint

Debian Samba Maintainers <pkg-samba-maint@lists.alioth.debian.org>
samba

Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>
illuminator

Debian Tcl/Tk Packagers <pkg-tcltk-devel@lists.alioth.debian.org>
tclreadline

Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>
twinkle

Barry deFreese <bdefreese@debian.org>
libphysfs (U)

Mattia Dongili <malattia@debian.org>
uml-utilities (U)

Ludovic Drolez <ldrolez@debian.org>
atftp

Zak B. Elep <zakame@zakame.net>
dbacl

Gerfried Fuchs <rhonda@debian.at>
qcake

Bdale Garbee <bdale@gag.com>
dump

Thomas Girard <thomas.g.girard@free.fr>
gnu-smalltalk (U)

Sergei Golovan <sgolovan@debian.org>
tclreadline (U)

Guido Günther <agx@sigxcpu.org>
multipath-tools (U)

John G. Hasler <jhasler@debian.org>
bc
chrony
units

Uwe Hermann <uwe@debian.org>
cdcd

Adam C. Powell, IV <hazelsct@debian.org>
evolver

IV" <hazelsct@debian.org>
illuminator (U)

Matthew Johnson <mjj29@debian.org>
ipmitool

Guillem Jover <guillem@debian.org>
inetutils

Timo Jyrinki <timo@debian.org>
malaga

Morten Kjeldgaard <mok@bioxray.au.dk>
torque

Michael Koch <konqueror@gmx.de>
cyphesis-cpp

Antonin Kral <A.Kral@sh.cvut.cz>
atari800

Kilian Krause <kilian@debian.org>
twinkle (U)

Richard Kreckel <kreckel@ginac.de>
ginac

Noèl Köthe <noel@debian.org>
lftp
lustre (U)
samba (U)

Steve Langasek <vorlon@debian.org>
samba (U)

Alexander Lazarević <laza@blobworks.com>
gnu-smalltalk (U)

Roger Leigh <rleigh@debian.org>
gutenprint (U)

Robert Lemmen <robertle@semistable.com>
eukleides

WANG Lu <coolwanglu@gmail.com>
scanmem

Mikael Magnusson <mikma@users.sourceforge.net>
twinkle (U)

Camm Maguire <camm@debian.org>
gcl

Jordi Mallach <jordi@debian.org>
torque (U)
xqf

Santiago Garcia Mantinan <manty@debian.org>
twinkle (U)

Cleto MartÃ*n <cleto.martin@gmail.com>
zeroc-ice (U)

Patrick Matthäi <pmatthaei@debian.org>
glusterfs
libphysfs (U)

A Mennucc1 <mennucc1@debian.org>
dvbstreamer

Kartik Mistry <kartik@debian.org>
scanmem (U)

Steffen Moeller <moeller@debian.org>
acedb (U)
torque (U)

Christophe Monniez <christophe.monniez@fccu.be>
afflib (U)

Francisco Moya <paco@debian.org>
zeroc-ice

Xavier Oswald <xoswald@debian.org>
gftp

Keith Packard <keithp@keithp.com>
nickle

Kasper Peeters <kasper.peeters@aei.mpg.de>
lie (U)

Javier Fernandez-Sanguino Pen~a <jfs@debian.org>
honeyd

Christian Perrier <bubulle@debian.org>
samba (U)

Stuart Prescott <stuart+debian@nanonanonano.net>
pyxplot

Mark Purcell <msp@debian.org>
twinkle (U)

Jan Hauke Rahm <jhr@debian.org>
bacula (U)

Andrés Roldán <aroldan@debian.org>
eresi

Kevin M. Rosenberg <kmr@debian.org>
ctsim

Ritesh Raj Sarraf <rrs@debian.org>
multipath-tools (U)

Daniel Schepler <schepler@debian.org>
ddd

Andreas Schuldei <andreas@schuldei.org>
uml-utilities (U)

Carlo Segre <segre@debian.org>
fityk

Gürkan Sengün <gurkan@linuks.mine.nu>
lie

Gürkan Sengün <gurkan@phys.ethz.ch>
gnudatalanguage

Jose Carlos Garcia Sogo <jsogo@debian.org>
twinkle (U)

Enrico Tassi <gareuselesinge@debian.org>
lua5.2

Andreas Tille <tille@debian.org>
acedb (U)

Ralf Treinen <treinen@debian.org>
yap

User Mode Linux Maintainers <pkg-uml-pkgs@lists.alioth.debian.org>
uml-utilities

Jelmer Vernooij <jelmer@debian.org>
samba (U)

Chris Waters <xtifr@debian.org>
tclreadline (U)

Colin Watson <cjwatson@debian.org>
spectemu

Patrick Winnertz <winnie@debian.org>
lustre (U)

Sven Joachim <svenjoac@gmx.de> writes:

> The two exceptions are [...] nvidia-cuda-toolkit (non-free,
> binary-only(?)).

Yup, binary-only. I believe the dependency is present in the binary that
we get from upstream, and no -dev packages are used since we don't build
the binary.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87zkgw3agt.fsf@windlord.stanford.edu">http://lists.debian.org/87zkgw3agt.fsf@windlord.stanford.edu

On 2011-10-20 00:03 +0200, Russ Allbery wrote:

> Sven Joachim <svenjoac@gmx.de> writes:
>
>> The two exceptions are [...] nvidia-cuda-toolkit (non-free,
>> binary-only(?)).
>
> Yup, binary-only. I believe the dependency is present in the binary that
> we get from upstream, and no -dev packages are used since we don't build
> the binary.

You may be missing some library build dependencies, though. The
nvidia-cuda-gdb package depends on libc6, libexpat1, libncurses5 and
libstdc++6, none of which are listed in Build-Depends although
dpkg-shlibdeps obviously found them.

While libc6 and libstdc++6 are unlikely to be removed from the
Build-Essential closure anytime soon, the same is not true for
libncurses5.

Cheers,
Sven


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87zkgwjdvt.fsf@turtle.gmx.de">http://lists.debian.org/87zkgwjdvt.fsf@turtle.gmx.de

Sven Joachim <svenjoac@gmx.de> writes:
> On 2011-10-20 00:03 +0200, Russ Allbery wrote:

>> Yup, binary-only. I believe the dependency is present in the binary
>> that we get from upstream, and no -dev packages are used since we don't
>> build the binary.

> You may be missing some library build dependencies, though. The
> nvidia-cuda-gdb package depends on libc6, libexpat1, libncurses5 and
> libstdc++6, none of which are listed in Build-Depends although
> dpkg-shlibdeps obviously found them.

Ah, indeed, good point. I thought we had Build-Depends on the library
packages instead of the dev packages, but we don't.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aa8waxb9.fsf@windlord.stanford.edu">http://lists.debian.org/87aa8waxb9.fsf@windlord.stanford.edu

On Wed, Oct 19, 2011 at 11:06:20PM +0200, Sven Joachim wrote:
> Colin Watson <cjwatson@debian.org>
> spectemu

Fixed in 0.94a-13, thanks.

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111020120555.GA20034@riva.dynamic.greenend.org.u k">http://lists.debian.org/20111020120555.GA20034@riva.dynamic.greenend.org.u k

Hi,

On Wed, Oct 19, 2011 at 11:06:20PM +0200, Sven Joachim wrote:
> Recently the readline-dev package and its GPL2 variant
> libreadline-gplv2-dev dropped their dependencies on libncurses5-dev.
> […]
>
> In the end I found 58 such packages on i386 in unstable/experimental,
> all but two of which build-depend on one of the libreadline*-dev
> packages. Since those are potentially RC-buggy, they probably deserve a
> look.
> […]

Thanks for the heads up.

> Mirco Bauer <meebey@debian.org>
> mono-debugger (U)
> […]
> Debian Haskell Group <pkg-haskell-maintainers@lists.alioth.debian.org>
> haskell-readline

Both uploaded.

Thanks,

--
Iain Lane [ iain@orangesquash.org.uk ]
Debian Developer [ laney@debian.org ]
Ubuntu Developer [ laney@ubuntu.com ]
PhD student [ ial@cs.nott.ac.uk ]

On 2011-10-20 14:05 +0200, Colin Watson wrote:

> On Wed, Oct 19, 2011 at 11:06:20PM +0200, Sven Joachim wrote:
>> Colin Watson <cjwatson@debian.org>
>> spectemu
>
> Fixed in 0.94a-13, thanks.

Actually, just adding the build dependency is not the best solution in
such cases, since you'll get a spurious dependency on libncurses5
(dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided
if "debian/spectemu-x11/usr/bin/xspect" were not uselessly linked
against it (they use none of its symbols)).

TRT is to patch the upstream build system and fix the
configure.in/configure.ac/Makefile files which erroneously believe that
-lncurses/-lcurses/-ltermcap is necessary for linking against readline.

Though with build systems that use -ltermcap rather than -lcurses (like
spectemu does), the next ncurses upload will bring some relieve
automatically by linking against tinfo rather than ncurses[1,2].

Cheers,
Sven


1. http://anonscm.debian.org/gitweb/?p=collab-maint/ncurses.git;a=commit;h=678cb35a4193212887e1d1455aa 56faa26808cd3
2. http://anonscm.debian.org/gitweb/?p=collab-maint/ncurses.git;a=commit;h=0b403f0b648ecc0d64e106e83df 36da68fabb029

On Thu, Oct 20, 2011 at 08:48:20PM +0200, Sven Joachim wrote:
> On 2011-10-20 14:05 +0200, Colin Watson wrote:
> > On Wed, Oct 19, 2011 at 11:06:20PM +0200, Sven Joachim wrote:
> >> Colin Watson <cjwatson@debian.org>
> >> spectemu
> >
> > Fixed in 0.94a-13, thanks.
>
> Actually, just adding the build dependency is not the best solution in
> such cases, since you'll get a spurious dependency on libncurses5
> (dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided
> if "debian/spectemu-x11/usr/bin/xspect" were not uselessly linked
> against it (they use none of its symbols)).
>
> TRT is to patch the upstream build system and fix the
> configure.in/configure.ac/Makefile files which erroneously believe that
> -lncurses/-lcurses/-ltermcap is necessary for linking against readline.

Ah, thanks. That's more effort than I expected anyone else to go to for
investigating a contrib package. ;-) Fixed properly in 0.94a-14.

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111021101347.GB20034@riva.dynamic.greenend.org.u k">http://lists.debian.org/20111021101347.GB20034@riva.dynamic.greenend.org.u k

On 2011-10-21 12:13 +0200, Colin Watson wrote:

> On Thu, Oct 20, 2011 at 08:48:20PM +0200, Sven Joachim wrote:
>>
>> Actually, just adding the build dependency is not the best solution in
>> such cases, since you'll get a spurious dependency on libncurses5
>> (dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided
>> if "debian/spectemu-x11/usr/bin/xspect" were not uselessly linked
>> against it (they use none of its symbols)).
>>
>> TRT is to patch the upstream build system and fix the
>> configure.in/configure.ac/Makefile files which erroneously believe that
>> -lncurses/-lcurses/-ltermcap is necessary for linking against readline.
>
> Ah, thanks. That's more effort than I expected anyone else to go to for
> investigating a contrib package. ;-)

Actually I'm investigating (i.e. building) all of these packages, and
the vast majority of them has the same problem. Only a handful or so
have reason to link against ncurses. I'll send a status update soon.

> Fixed properly in 0.94a-14.

Thanks!

Cheers,
Sven

On 2011-10-19 23:06 +0200, Sven Joachim wrote:

> Recently the readline-dev package and its GPL2 variant
> libreadline-gplv2-dev dropped their dependencies on libncurses5-dev.
> This prompted me to look for packages that currently depend on
> libncurses5 but do not build-depend on libncurses5-dev or its aliases
> libncurses-dev and ncurses-dev, nor have libncurses5-dev pulled in via
> other means.
>
> In the end I found 58 such packages on i386 in unstable/experimental,
> all but two of which build-depend on one of the libreadline*-dev
> packages.

One of those 56 packages (atari800) should not have been in the list,
since libncurses5-dev _is_ pulled in by its other build dependencies,
and four packages had maintainer uploads adding libncurses5-dev to
Build-Depends, which is the easiest though not necessarily the best fix.
This leaves 51 packages to check, which fall into four categories. A
(*) indicates that the problem vanishes if libtinfo-dev provides
libtermcap.so as an alias to libtinfo.so (see #644426).


a. Packages which FTBFS due to unrelated problems (6):
================================================== ====
ctsim #642709
cyphesis-cpp #606724
gnudatalanguage #642715
gutenprint #639071
sqlite #646032
sqlite3 #642584

I haven't really looked at those.


b. Packages which FTBFS due to -lncurses etc. not available (21):
================================================== ===============
acedb
cdcd
ddd
dvbstreamer
eresi
eukleides
evolver
gnu-smalltalk
illuminator
inetutils
lftp
libphysfs
lie
lua5.2
multipath-tools
qcake
tclreadline (*)
twinkle
udftools
uml-utilities
zeroc-ice

I'll file bugs against those in short order.


c. Packages which build, but disable readline support (8):
================================================== ========
bacula
chrony
dbacl
gcl
glusterfs (*)
lustre
malaga
xqf

This is an even worse category, since the next rebuild of those packages
could silently drop functionality. Which severity would be more
appropriate for bug reports, "important" or "serious"?


d. Packages which build fine (16):
==================================
atftp
bc
dump
fityk
gftp
ginac
gnokii
honeyd
ipmitool
nickle
samba
scanmem
torque
units
yap
yaz

Those are candidates for bug reports at low severity. I don't intend to
file those bug reports myself.

Cheers,
Sven