[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packages depending on libncurses5 but not build-depending on libncurses-dev



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

Attachment: pgpRjBmQkSVdi.pgp
Description: PGP signature


Reply to: