3 # Purpose : Explain the content of the multi-binary scripts folder
5 # Copyright : Written by and Copyright (C) 2001-2012 the
6 # Privoxy team. http://www.privoxy.org/
8 # This program is free software; you can redistribute it
9 # and/or modify it under the terms of the GNU General
10 # Public License as published by the Free Software
11 # Foundation; either version 2 of the License, or (at
12 # your option) any later version.
14 # This program is distributed in the hope that it will
15 # be useful, but WITHOUT ANY WARRANTY; without even the
16 # implied warranty of MERCHANTABILITY or FITNESS FOR A
17 # PARTICULAR PURPOSE. See the GNU General Public
18 # License for more details.
20 # The GNU General Public License should be included with
21 # this file. If not, you can view it at
22 # http://www.gnu.org/copyleft/gpl.html
23 # or write to the Free Software Foundation, Inc.,
24 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
27 # Modification : If you modify this file please consider whether your
28 # changes ought to be passed back to the macsetup module.
31 These multi-binary pre/postinstall scripts are unfinished, and indeed now lack features present in the single-binary versions since development focussed there after the fork.
33 The intent was to compile multiple single-architecture binaries targeting each OS X release then detect the target OS X version and processor architecture at install time, copying into place only the one necessary binary. The benefit of this approach would be one single installer package for ALL OS X versions and reduced cruft on the target machine.
35 They are left in the project as the basis for potential future development, however their sole unique feature is unrelated to multi-binary support (indeed the single-binary scripts should be used as a starting point for any putative multi-binary support). The unique feature is in postinstall and is programmatic replacement of the package identifier in the uninstall script, thereby handling whatever pkg id is entered into the Packagemaker project. As things stand this replacement is instead handled by constructPkgContent.sh, which can only change the version number and therefore restricts the format of the package identifier string.