the qnx support is not yet ready. there are two open points:

   - fts.c is not compiling (needed code is included, but #ifdef not  
yet ready)
   - db 4.6.21 support DB_PRIVATE not yet finalised

let me know, what the schedule for 5.0.1 is, so i can see, if qnx  
support is still possible

but, i guess, that qnx support is not really a blocking issue ;-)

-piet


Am 27.01.2008 um 18:49 schrieb Jeff Johnson:

> AFAIK, all blocking issues for rpm-5.0.1 are resolved.
>
> Here's the items in the TODO:
>
>  - /usr/lib64 is reported not expanded into rpm.pc pkgconfig fle and
>        ___init.py___.
>
>  - distributing per-platform configuration needs to be done. At a  
> minimum,
>        the cpu-os.macros.tar.gz file needs distributing with the rpm  
> tarball.
>
>   - 2-4 applications are having trouble compiling against rpm-5.0.0,  
> largely
>        (my guess) because header.h has been removed. A stub to  
> retrofit
>        could be done, but then the question will become headerGetEntry
>        (and other) symbols. Which also could be retrofit'ed if there
>        as interest, noone replied when I asked repeatedly.  
> Alternatively,
>        just doing the port to rpm-5.0.0 is likely not hard at all.
>
> The first issue is reported to have a work around (from Michael  
> Jennings, holler if I misunderstand).
>
> The 2nd issue has to do solely with the release. The rpm.spec.in has  
> been
> updated, builds for me on Fedora, but there's likely some further  
> polishing.
>
> The last issue is likely best solved by porting net-snmp (and urpmi)  
> to
> rpm-5.0.0.
>
> There's also QNX support (done afaik), and rpmbuild --lsb fiddles  
> (ongoing),
> but none of those are critical to rpm-5.0.1.
>
> Any other issues?
>
> 73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org