Request 34 was acted upon.
_________________________________________________________________________
URL: https://rt.openpkg.org/id/34
Ticket: [OpenPKG #34]
Subject: Re: problem bootstrapping openpkg on Solaris
Requestors:
Queue: openpkg
Owner: Nobody
Status: open
Transaction: Correspondence added by rse
Time: Wed Jun 04 12:21:10 2003
________________________________________________________________________
> > 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:
We've not received any feedback from the user.
So, we would have to check our patch again ourself.
--
Ralf S. Engelschall
OpenPKG Project Leader
[EMAIL PROTECTED]
