> That package can then be opened using installer.app, but isn't usable as it. > > !) There are no pre/post scripts > > 2) User cannot select components > > 3) There is no README, License, custom logo, ... > > 4) I'm pretty sure this doesn't install the documentation > > It might be possible to add all missing features using pkgbuild and > productbuild, but I'm not sure about that.
It is possible to support all of those features. I have a semi-working prototype which I need to finish. One process issue is that (I believe) one can only create signable flat packages on newer systems (10.6+) although the package can be used on 10.5. So either we don't change the 32-bit installer for 3.3+ (which is 10.5 deployment target) only, or we go through an extra step to build it on 10.5 and then sign it on 10.6+, or we build and sign it on 10.6+. The 2.7 32-bit installer uses a 10.3 deployment target and changing that would be a de facto ABI change for its users and suppliers of binary extension modules. So, for 2.7, we could (1) continue to supply the old format installer, supporting installations on 10.3+; (2) continue to build as 10.3 deployment target but switch to the new installer format, thereby no longer providing a binary installer for 10.3 and 10.4 systems (users could still build it themselves); (3) add a 10.5+ installer for 2.7.x (like the ones for 3.3+). We could drop (1) and move to (2) and (3) for a release or two of 2.7.x and then consider dropping (2), assuming there is not a lot of negative feedback. It would be nice to not have to worry about 10.4- compatibility. -- Ned Deily, n...@acm.org _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
