Bug 525146

Package doesn't build:
...
+ rm /users/fedora/src/rpms/BUILDROOT/PDCurses-3.4-1.fc11.x86_64/usr/lib64/libXpanel.so
rm: cannot remove `/users/fedora/src/rpms/BUILDROOT/PDCurses-3.4-1.fc11.x86_64/usr/lib64/libXpanel.so': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.xmRHkF (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.xmRHkF (%install)

Odd.  Do the solibs it's trying to remove exist in $RPM_BUILD_ROOT/usr/lib?

This faile to build for me earlier in mock on 86_64 rawhide.

checking for X... libraries , headers
configure: error: Cannot find required X library; libXaw. PDCurses cannot be configured

https://koji.fedoraproject.org/koji/taskinfo?taskID=1701811

Note that i686 builds OK, but x86_64 fails; something is probably using a hardcoded /lib, which would tend to explain both problems.

Please clear the whiteboard when you have a package that builds.

(In reply to comment #3)
> something is probably using a
> hardcoded /lib,
Not quite. 

My issue originates from the fact that this package's toplevel Makefile.in does not acknowledge libdir (and other *dir's.

When having fixed this, other bugs show up:

* DESTDIR handling is broken

* shared lib without SONAME.
IMHO, inacceptable, esp. not for a package which aims at implementing something such kind of essential as a curses library.

* Several files from the devel-package conflict/clash with ncurses (MUSTFIX)

* The package installs an autoheader generated autoheader as /usr/include/config.h (MUSTFIX).

* The devel-package lumps together x11 and sdl libraries.
IMO, the x11, sdl and other lib subsets should be split into separate subpackages.

* The devel-package likely lacks deps on many other *-devel packages.
I haven't tried to check for details, yet.

* Shipping static libs. 
Jon, feel strongly encouraged not to ship them.

> Please clear the whiteboard when you have a package that builds.  
Urgh, what is this? More silly bureaucracy?

More serious issues:

* /usr/include/xcurses.h contains this:
typedef unsigned char bool;

This violates POSIX, ISO C etc.
c.f. http://www.opengroup.org/onlinepubs/9699919799/basedefs/stdbool.h.html

* /usr/bin/xcurses-config doesn't acknowledge libdir and doesn't filter out system libdirs/includedirs.

I'd suggest to replace this script with a pkgconfig wrapper (i.e. to add a *.pc and write an xcurses-config script using this *.pc)

So it would seem that PDCurses has major, major issues.  Not sure how I missed the conflicts with ncurses-devel.  Odd.

Anyway, IMHO we have no need for another curses implementation in Fedora, ncurses works wonderfully.  The only reason I've submitted this is that asciiportal needs it.  Given the above, I see three courses of action.

1. Fix the above.  Yow.

2. Create an asciiportal package that bundles PDCurses.  Since asciiportal builds against PDCurses statically (ick!) and I've not succeeded in getting it to build dynamically yet, this may work.  While bundling libs is to be avoided at all costs, I wonder about doing it when there's no intention of putting the lib in Fedora.  Food for thought.

3. Port asciiportal to ncurses.  Paradoxically, this might be the least work, if it's possbile. Haven't looked into it in any depth, however.


Any thoughts on these options?

(In reply to comment #6)
> Any thoughts on these options?  
Which parts of PDCurses does asciiportal actually need?

Theoretically, all curses implementations should be (more or less) compatible, so porting asciiportal to ncurses would be another option, i.e. I would definitely prefer your option 3).

Wrt. 1): Fixing the Makefile.in irons out many of the issues mentioned above, however there are parts, I don't see any way to fix, in particular the SDL bindings (IMO, they are a flawed, immature design. Upstream PDcurses was right in not integrating them into their "nominal" configuration)

2) is a non-go/no-way, non-option to me.

I agree that 3 is best and 2 is awful.  I just put 2 out there since it is technically possible.

Re 1 and 3, is is the SDL bindings that are the critical part, and, AFAICT, the reason PDCurses was selected of ncurses.  I'm not aware of any ncurses SDL bindings.  In a few cases in my own code, where I need both, I just use both, for instance I've written but not yet released a game using ncurses and SDL_mixer.

I think 3 would basically mean porting the PDCurses SDL bindings to ncurses.

Since this conflicts with ncurses, I'm withdrawing this review.