Re: Bug#2446: dpkg" source depends on /usr/include/ncurses .
In message <m0tsX43-0005xIC@mongo.pixar.com>, Bruce Perens writes:
>> Shouldn't ncurses3.0-dev deal with this problem from postinst.
>Only if you think /usr/include/ncurses is necessary for compatibility.
>The proper place to put the header is in /usr/include/curses.h .
Have you seen my message about how many autoconf scripts seem to use
that ncurses directory to determine whether they're working with
ncurses or BSD? If you have, have you factored that into your
statement above (which could be translated into, "please get rid of
the link that creates a /usr/include/ncurses")?
Also, I'd like some input from everyone on a related issue:
As I read it (and I can forward the entire mail to anyone interested,
since I am as prone as anyone to misinterpretation), Daniel Barlow has
proposed (on linux-gcc) that the gcc people standardize on
ncurses-1.9.8a (plus bugfixes as necessary) and---to the extent that
his proposal explicitly discusses future plans---not upgrade in the
forseeable future. He also proposes changing the soname to something
other than what the ncurses people determine.
_I_ think this is a mistake, and would like to put the weight of the
Debian project behind a statement to that effect, but before I speak
for the Debian project as a whole, I'd like to get other people's
feelings, because I know there have been some complaints here about
the shifting sonames and such.
I guess that I think it's a less than perfect solution for us to
ignore possible improvements---I don't necessarily want (or intend) to
track every release and patch blindly (and have not done so), but I
think it would be just as bad to freeze things in the way that seems
to have been proposed.
Also, I do realize that not everyone is using Debian, and thus not
everyone has access to our package tools and such, but I don't think
it's inappropriate for the Debian project to base its input on the
requirements and capabilities of our tools.
"You could have it all, my empire of dirt."