New Installer for PHP 5.2

On 24-Jul-06, at 10:52 AM, John Mertic wrote:

I'd say it should contain all of the extensions that are enabled by- default.

I think if the 1st is done the size of the file should be much smaller, if not we can examine the enabled extensions one by one and perhaps turn off some of the "less important" ones. Ilia Alshanetsky

John Mertic wrote:

So what is included over the 2.7Mb of the existing 5.1.4 installer? ( I presume there is no plan to remove the more useful zip file ;) )

Hi John, I looked at this already (bless irc) and it looks great.. chm manual option's a nice touch :) The main questions I have about it are: 1) I didn't notice anywhere to choose the path for the install. (This might be because I only tested with cli?) That makes it kinda hard to figure out where the installed version went :) I eventually found it in PROGRA~1, which might be the default for registry-based installations but was (perhaps strangely) not where I'd have immediately expected it to be from a desktop test install. 2) Same goes for the php.ini, the whereabouts of which can be fairly critical depending on the setup. (Those two I think are probably important.) 3) is there some way to have (version-compatible) components 'install on demand', rather than download the whole lot at one go? (Would be useful if...) 4) enabling extensions via the installer at present simply means adding them to the end of the existing php.ini, i.e. the same module can be listed twice, once disabled and once enabled. Is there no way to do a search and replace on the existing string or simply write that part of the file from scratch? - because at present, people will still need to make manual modifications to their .ini following installation, and it's confusing. 5) is there - or will there be - a way to update components via the installer? or even the core? (would mean disabling/deleting non-compatible components) 6) is there - or will there be - any way to set up the chosen server configuration via the installer (for all servers or even just for Apache?) - again, I didn't test with a server install so this might be in place already. 7) how about further php.ini modifications? - remembering that the existence of many directives depends on the extensions installed. (These come under 'would be sweet if...') Further comment: I personally think it creates more problems than it solves to differentiate between core and PECL extensions. IMHO it'd be better to throw them all together in alphabetical order and simply have everything 'already on' that is enabled by default. This'll also help when items get shifted around, as they inevitably do... components shipped with the core that aren't yet in PECL would need to be downloaded with the core anyway because there's no other way to reach them individually, so there _is_ that difference, but that 'core list' is not writ in stone and changes quite frequently. Just some feedback - even if you do nothing more to it it's still pretty neat :) - Steph oh ps - PEAR install yes/no doesn't appear to work - you get .phar either way. Is that intentional for now? ----- Original Message ----- From: "John Mertic" <jmertic@gmail.com> To: <internals@lists.php.net> Sent: Monday, July 24, 2006 4:52 PM Subject: [PHP-DEV] New Installer for PHP 5.2

Hi John, Good work :) Any chance you could publish the WiX files for this? I haven't tried it yet, but based on the comments of others, and experience of my own with WiX in a complex product, here are my comments :-) - I think we have way too many PHP extensions to make a checkbox installation per extension a viable option. How do you handle upgrades--does the installer remember which options you checked last time? - It sounds like you're putting stuff in the registry. While that's "fine" if you only have one version of PHP installed, it will screw up people that need to run different versions at the same time. Can this be made optional? - Registering .php to run with php-win.exe. I feel nervous about this--it wouldn't take much for someone to create a malicious .php attachment and exploit some poor soul who has PHP installed; it should be made clear why you'd want to do it and why it might be dangerous. I don't know if you've covered it in your installer already, but you can also register PHP with the event logging infrastructure in windows so that syslog() messages look "nice" in the event log. This is quite simple to do; the windows build does this when you "nmake install". That's all for now; keep up the good work :) --Wez. On 7/24/06, John Mertic <jmertic@gmail.com> wrote: