[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openpkg-users
Subject:    Re: problem bootstrapping openpkg on Solaris
From:       "Ralf S. Engelschall" <rse () engelschall ! com>
Date:       2002-07-17 7:29:59
[Download RAW message or body]


In article <D7A3CFD7825BD6119B880002A58F06C227E704@groexmb02.pfizer.com> you wrote:

> First, this is a tremendously useful project.  I've been looking for a
> straightforward way to install opensource software in a NFS-shareable
> location that would properly enforce library dependencies.  The openpkg
> tools work very well for this.
> 
> I bootstrapped openpkg but had considerable problems building source
> packages until I discovered that on my system, BUFSIZ is defined to be 1024
> in /usr/include/iso/stdio_iso.h, included from /usr/include/stdio.h.   This
> is much smaller than the 8192 that (seems to be) the value that RPM expects
> (noted in the comments /Volumes/app/appman/RPM/SRC/rpm-4.0.2).  
> 
> The effect was that the long installation path name (not my choice),
> /net/gsun492/Volumes/app/appman/, was causing the __build_pre macro to
> overflow its buffer and get truncated, resulting in general havoc.   (It
> seems likely that short paths (/cm/) would not cause the problem to occur.)

I've looked into the RPM sources and it seems that RPM uses the POSIX
BUFSIZ (usually historically intended for maximum pathname length and in
POSIX for the setvbuf stuff) for really any type of buffers, including
macro expansion buffers. This certainly is a bad coding style and
predestined to fail - as you discovered here.

Just replacing all BUFSIZ occurences with an own (and numerically
larger) definition is not recommended, because it would not just change
the buffer sizes in the macro parts (where it is needed), but also in
the I/O parts (where it is correct). A possible side-effect could be
that an I/O buffer could be larger than usually expected and lead to I/O
latency problems, whatever.

So, IMHO the correct fix is to change only the RPM macro code to use
a larger buffer. Can you try the following patch (against the latest
OpenPKG-CURRENT "openpkg" package) and give feedback whether it also
fixes your problems:

Index: openpkg.spec
===================================================================
RCS file: /e/openpkg/cvs/openpkg-src/openpkg/openpkg.spec,v
retrieving revision 1.82
diff -u -d -u -d -r1.82 openpkg.spec
--- openpkg.spec        14 Jul 2002 12:50:57 -0000      1.82
+++ openpkg.spec        17 Jul 2002 07:26:51 -0000
@@ -408,6 +408,9 @@
       sed -e 's;^\(SUBDIRS[    ]*=.*\) po$;\1;' \
           <popt/Makefile.in >popt/Makefile.in.n && \
           mv popt/Makefile.in.n popt/Makefile.in
+      sed -e 's;BUFSIZ;8192;g' \
+          <rpmio/macro.c >rpmio/macro.c.n && \
+          mv rpmio/macro.c.n rpmio/macro.c
       ( echo 'ac_cv_path_MSGFMT=${ac_cv_path_MSGFMT=no}' 
         echo 'ac_cv_path_GMSGFMT=${ac_cv_path_GMSGFMT=no}' 
       ) >config.cache

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com
______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
User Communication List                      openpkg-users@openpkg.org
[prev in list] [next in list] [prev in thread] [next in thread]