Ned Deily added the comment: After a fair amount of research, trial-and-error, and testing on all of the OS X platforms we support, I think we're now ready to switch to signed flat packages for the OS X installers and thereby greatly improve the user installation experience on current systems. I've found that it *is* possible to produce signed installers that work as expected on the same set of o/s releases and platforms as the current legacy installers (i386/ppc for 10.5+ and x86_64/i386 for 10.6+), with the same set of user installation options, although there were a number of gotchas along the way. One unexpected issue was that our Python frameworks are not immutable - since they include install paths such as the site-packages and scripts directories - and the current Apple packaging tools aren't designed to support a configuration like that. On newer releases where codesigning is fully supported, the installer wants to treat framework bundles as atomic elements which, I discovered, can result in the user' s site-installed packages being deleted during an maintenance release upgrade. I was able to work around that in a way that works across all supported releases but it does point out that we should consider modifying our framework deployments to move to "read-only" bundles if possible.
We produce the two installer variants by running build-installer.py on two different OS X systems (10.5 and 10.6) and then move the resultant bundle installers encapsulated in OS X disk image files (.dmg) to a third current (10.9) system for pgp signing, archiving, and uploading. The new process, beginning with the upcoming 3.4.2, remains the same except that the build artifacts from the two builds are now post-processed on the 10.9 system using the current Apple packaging tools to produce the flat package installer files and to do the "Gatekeeper" signings. For 3.4.2rc1, the configuration files for the packaging tools have been manually generated. The next step, probably post-3.4.2, will be for build-installer.py to auto-generate the config files. Another advantage of flat-format installers is that they are a compressed single file and don't need to be wrapped in another container like the legacy bundle installers do. So, starting with 3.4.2, the installer file (.pkg) will be downloaded directly rather than within a .dmg file. This simplifies the user installation process: double-clicking on the downloaded .pkg file will start the installer directly rather than having to click on the downloaded dmg, waiting for it to mount, double-clicking on the installer file in the window that opens, and remembering to dismount the volume when the install is complete. And, in some browser configurations, the installer will be launched automatically, although in all cases, user action is still required to complete the install. One possible downside to eliminating the dmg (or similar) container is that there will no longer be a redundant readme file outside of the installer. The installer presents the package's welcome, readme, and licens e files and the opportunity for the user to save and/or print each, but previously we also made a copy of the readme file available in the dmg directory next to the installer file. The primary case where that could be useful is if the user cannot launch the installer for some reason and the readme provides a workaround. But that unusual case is the one we are fixing by moving to signed packages. Not surprisingly, many users do not read readmes anyway: the previous readme files did include instructions on how to workaround the Gatekeeper issue yet many users still had problems. In the unlikely event that a similar problem arises, we still have the option to revert to a zip or a dmg if just providing info on the python.org download pages proves insufficient. To address the points in the original issue: (1) I think the risk has been minimized as there are no changes to the actual installer builds and the user experience in the installer is virtually unchanged; what we have changed is removing obstacles to getting to the installer. (2) While I still think in the long run it would be best to have a PSF-owned Apple developer company account for signing (and I still intend to pursue that with the board at some point after coming up with a concrete proposal), I don't think it is a particularly pressing issue. Initially, the installers are being signed with my personal developer id, just as other release files are signed by the personal pgp keys of the release team members who produce them. Unlike the Windows installer, the OS X installer does not display information about the signing key unsolicited other than an indication that one is present if you know where to look. There's a small icon indicating a signed installer in the upper-right corner of the installer window; clicking it causes the certificate info to be displayed. (3) is no longer an issue. As noted, we have already dropped installer support for OS X 10.3 and 10.4 in 3.x releases. Because of the extended life of the 2.7 series, with 2.7.7, we started the deprecation of those old systems by adding a 10.5+ format installer similar to 3.x releases while continuing to provide a 10.3+ format. With the next 2.x release (2.7.9) we plan to drop the 10.3+ installer altogether. So, going forward, all release installers will be flat and signed. Note that the daily dmg buildbot is still producing (old-format) test installers on a 10.4 system, which should help to ensure we don't needlessly break things on older systems. ---------- type: enhancement -> behavior versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15661> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
