|Summary:||Review Request: PDCurses - Public Domain curses library|
|Product:||[Fedora] Fedora||Reporter:||Gwyn Ciesla <gwync>|
|Component:||Package Review||Assignee:||Nobody's working on this, feel free to take it <nobody>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||fedora-package-review, notting, pahan, rc040203|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-10-29 12:20:06 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Gwyn Ciesla 2009-09-23 14:34:33 UTC
A public domain curses library for DOS, OS/2, Win32, X11 and SDL, implementing most of the functions available in X/Open and System V R4 curses. It supports many compilers for these platforms. The X11 port lets you recompile existing text-mode curses programs to produce native X11 applications. SRPM: http://zanoni.jcomserv.net/fedora/PDCurses/PDCurses-3.4-1.fc11.src.rpm SPEC: http://zanoni.jcomserv.net/fedora/PDCurses/PDCurses.spec
Comment 1 Ralf Corsepius 2009-09-23 16:20:32 UTC
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)
Comment 2 Gwyn Ciesla 2009-09-23 16:50:36 UTC
Odd. Do the solibs it's trying to remove exist in $RPM_BUILD_ROOT/usr/lib?
Comment 3 Jason Tibbitts 2009-09-23 20:38:27 UTC
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.
Comment 4 Ralf Corsepius 2009-09-24 03:20:01 UTC
(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?
Comment 5 Ralf Corsepius 2009-09-24 04:10:53 UTC
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)
Comment 6 Gwyn Ciesla 2009-09-24 12:39:18 UTC
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?
Comment 7 Ralf Corsepius 2009-09-24 14:05:20 UTC
(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.
Comment 8 Gwyn Ciesla 2009-09-24 14:45:52 UTC
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.
Comment 9 Gwyn Ciesla 2009-10-29 12:20:06 UTC
Since this conflicts with ncurses, I'm withdrawing this review.