New Installer for PHP 5.2

Thanks to Edin Kadribasic, the public test version ( which installs a
recent snapshot of PHP 5.2 ) is located at
http://downloads.php.net/edink/php-5.2.0-win32-installer.msi.

I am looking for feedback on the installer, namely in the following
areas:

• Default install options; what should the default install consist of?

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

• Lite Installer. The current install file weighs in at 18mb. Would we
  want a lite installer with fewer components and if so what would those
  be?

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:

• Lite Installer. The current install file weighs in at 18mb. Would we
  want a lite installer with fewer components and if so what would those
  be?

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 ;) )

--
Lester Caine - G8HFL

L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php

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 there,

With the guidance of Phil Driscoll, I have put together a new
installer for PHP on Windows. It replicates much of the same
functionality of his installer, but also boasts the following
features:

• Selective installation of all PHP components ( CGI and CLI exes,
  server modules, standard and PECL extensions ).
• Configures the php.ini for the installation, including enabling the
  extensions the user selected to install.
• Built as an MSI using Wix (http://wix.sourceforge.net) which is
  scriptable and open source so we can include the code to build the
  installer in cvs and automate building it. Also MSI Installers are
  very useful for Sys Admins since they integrate into Group Policies to
  allow unattended installation, and are better supported on Windows in
  general.

Thanks to Edin Kadribasic, the public test version ( which installs a
recent snapshot of PHP 5.2 ) is located at
http://downloads.php.net/edink/php-5.2.0-win32-installer.msi.

I am looking for feedback on the installer, namely in the following areas:

• Default install options; what should the default install consist of?
• Lite Installer. The current install file weighs in at 18mb. Would we
  want a lite installer with fewer components and if so what would those
  be?

--
Later,

John Mertic
"Explaining a joke is like dissecting a frog: you
jmertic@gmail.com understand it
better, but the frog dies in the

process."

                                        -Mark Twain

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.

Hi there,

With the guidance of Phil Driscoll, I have put together a new
installer for PHP on Windows. It replicates much of the same
functionality of his installer, but also boasts the following
features:

• Selective installation of all PHP components ( CGI and CLI exes,
  server modules, standard and PECL extensions ).
• Configures the php.ini for the installation, including enabling the
  extensions the user selected to install.
• Built as an MSI using Wix (http://wix.sourceforge.net) which is
  scriptable and open source so we can include the code to build the
  installer in cvs and automate building it. Also MSI Installers are
  very useful for Sys Admins since they integrate into Group Policies to
  allow unattended installation, and are better supported on Windows in
  general.

Thanks to Edin Kadribasic, the public test version ( which installs a
recent snapshot of PHP 5.2 ) is located at
http://downloads.php.net/edink/php-5.2.0-win32-installer.msi.

I am looking for feedback on the installer, namely in the following areas:

• Default install options; what should the default install consist of?
• Lite Installer. The current install file weighs in at 18mb. Would we
  want a lite installer with fewer components and if so what would those
  be?

--
Later,

John Mertic
"Explaining a joke is like dissecting a frog: you
jmertic@gmail.com understand it
better, but the frog dies in the

process."

                                         -Mark Twain

Hi John

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.)

On the page where you choose the components to install, you'll see the
location underneath the tree widget, with a browse button to locate
where to put it. It's somewhat non-obvious though, I'm not sure how
much of an issue it is ( I know many MSI based installers are laid out
in the same fashion ).

Too much information on that page, is why I didn't notice it. I think it
probably
needs a design rethink, but see what other feedback you get - it's been a
long
day here ;)

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.

What I'll probably do is remove the extension directives from where
they normally are and keep them at the bottom; this is in line with
how many packages that edit the php.ini file work.

Yep good - note a few minor problems with layout though:

; Local Variables:
; tab-width: 4
; End:
[PHP_JSON]
extension=php_json.dll

• it shouldn't be after vi settings (simply write them last?), and
  'extension' is not a PHP_JSON directive - it's a [PHP] directive and should
  be part of the main clause.

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)

It will support upgrading from one PHP version to another, and will
upgrade the included components that come with that version.

That's very cool, but it also needs to check the version compatibility of
whatever PECL-only extensions happen to be loaded... otherwise there's a
chance they'll mysteriously stop working.

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.

IIS CGI and Xitami will be configured automatically ( and we could add
Sambar to that list if there is interest ), but Apache uses a wierd
config file format that I don't have a good tool to edit.

httpd.conf's weird? It's only a text file :) the complication's in the fact
that there's more than one way to set it up. But you could offer automated
basic CGI setups pretty easily using the paths you've already been given for
php.exe and php.ini, and the module setup actually isn't that complicated
either, assuming you already know it's an apache module setup that's
required.

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...')

We do many of these, such as enabling cgiforceredirect,
upload_tmp_dir, and session.save_path, along with adding Registry Keys
and Enviroment variables that are needed under Windows ( after install
try typing 'php -v' at the command line and it should find the PHP
install correctly ). I also register .php files to open with
php-win.exe if you install the 'Script Program' option.

Actually typing php -v and php -m was how I found out it was registered :)
Didn't know you'd set some of those options because I only tested a couple
of odd extensions to see how it was set up. That said, gd was one of those
extensions, and I didn't see an option to reset gd.jpeg_ignore_warning - did
you only look at directives involving paths for now?

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.

I agree and disagree. While it will be simplier to install the
extensions, it would also be helpful to know which ones are
supported and which ones are not. I'd welcome any suggestions here.

Well, since there's no way to get that information anyway until you try to
download a .dll that doesn't exist or is incompatible with the version of
PHP you're running, I'd suggest trying to download a .dll and producing
error messages in those cases. Everything in PECL (that is released at all)
has a package.xml file that contains all sorts of useful information
regarding versioning, requirements and maintenance status... perhaps ask
Edin to supply that file via a channel that also supplies the .dll (where it
exists)? (Note: my understanding of channels is very, very hazy and I'm
probably sending you the wrong direction by even using the term, but Edin'll
know what I mean...)

oh ps - PEAR install yes/no doesn't appear to work - you get .phar either
way. Is that intentional for now?

WFM, can anyone else confirm this?

My bad, I didn't spot that it's enabled by default. Back to the TMI thing...
I honestly think you should split that page into separate serial pages for
a) the actual PHP install, b) the server stuff, c) the extensions, d)
peripherals (aka PEAR and docs). I'm not a naive user by any stretch of the
imagination, but I'm missing things all over the shop on that page.

• Steph

Thanks for the feedback....

--
Later,

John Mertic
"Explaining a joke is like dissecting a frog: you
jmertic@gmail.com understand it
better, but the frog dies in the

process."

                                        -Mark Twain