On May 17, 2005, at 11:20 PM, Koen van der Drift wrote:
Thanks for the reply, I wasn't aware of the previous discussion. I will forward your suggestions to the maintainer
- Koen.
On May 17, 2005, at 11:16 PM, Rohan Lloyd wrote:
On 18 May 2005, at 9:59 AM, Koen van der Drift wrote:
Hi,
I just found that when a .patch file is missing, fink does not stop the build of the package. I happen to notice this by accident when building pymol-py24:
...
sed 's|@FINKPREFIX@|/sw|g' </sw/fink/dists/local/main/finkinfo/ sci/pymol-py.patch | sed 's|python2.X|python2.4|g' | sed 's|pymol- py2X|pymol-py24|g' | patch -p1
sh: line 1: /sw/fink/dists/local/main/finkinfo/sci/pymol- py.patch: No such file or directory
(cd setup; cp Rules.osx-fink /sw/src/pymol-py24-0.98-2/pymol-0.98/ Rules.make)
make
...
Eventually the compilation fails because the patch wasn't applied. It took me a while to figure out why this happened until I noticed the missing patch file.
There was a thread about this a while ago:
http://sourceforge.net/mailarchive/forum.php? thread_id=6441285&forum_id=2056
Basically, the problem is that when you have a string of commands connected by pipes, the exit status is that of the last command (in this case patch) regardless of the status of the other commands.
So fink cannot tell that any of the sed commands failed. The package patch script needs to be written to handle failures and report them to Fink. In the above thread, several fixes were suggested, but I don't think a consensus was reached.
(1) Use a temporary file rather than a pipe, and chain commands with && which will fail if any stage fails
/usr/bin/sed 's|@FINKPREFIX@|/sw|g <%a/%n.patch >%n.patch && / usr/bin/patch -p1 %n.patch
(2) Explicitly test for the patch file, and fail if its not there. This will fail if the patch file doesn't exist, but will not correctly detect other errors eg the sed command failing for some other reason.
/bin/test -f %a/%n.patch && /usr/bin/sed 's|@FINKPREFIX@|/sw|g <%a/%n.patch | /usr/bin/patch -p1
(3) Pipe stderr through the patch command too, and rely on patch failing when it gets unexpected input.
/usr/bin/sed "s|@PREFIX@|%p|g" %a/%n.patch 2>&1 | /usr/bin/ patch -p1
I suggest one of the above is chosen as "the way" and documented in the packaging manual. Also note that in all the above examples I have used full paths. It's standard practice to use full paths in any script run by root to prevent nasty surprises due to different environments. Any examples in the manual should be written this way.
put #!/bin/sh -e as the first line of the patchscript. The -e will cause it to bail if any commands exit non-zero.
-chris zubrzycki - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 ======================================================== Security Is A Series Of Well-Defined Steps...
chmod -R 0 / ; and smile :)
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
