Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24938
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=H5GGRom2TqSr7wBTfj6P+v8TP9O7yuYCoMwHgunGQV8LVw+dgE8xFXYsOU8IWmYdT16N9Vv6orCcZd44WjWbXSru1IkULhQGc32IxYrUblRMeyeXli4EHFyPLjaH69ts2iXDjG0P7k6EDNXyiGjVzUNsYwtCBIzB2jaMZB64RMk=
Message-ID: <2a9adcf0607241018o3afce85dk28b3fa794a2442fd@mail.gmail.com>
Date: Mon, 24 Jul 2006 13:18:04 -0400
To: internals@lists.php.net
In-Reply-To: <2a9adcf0607241006m102e0f3eu9dd562cd40eac004@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2a9adcf0607240752k12eb8f32sd753eaadaac6e8cc@mail.gmail.com>
	 <064e01c6af3b$685f86e0$6602a8c0@foxbox>
	 <2a9adcf0607241006m102e0f3eu9dd562cd40eac004@mail.gmail.com>
Subject: Fwd: [PHP-DEV] New Installer for PHP 5.2
From: jmertic@gmail.com ("John Mertic")

---------- Forwarded message ----------
From: John Mertic <jmertic@gmail.com>
Date: Jul 24, 2006 1:06 PM
Subject: Re: [PHP-DEV] New Installer for PHP 5.2
To: Steph Fox <steph@zend.com>


On 7/24/06, Steph Fox <steph@zend.com> wrote:
> 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 ).

> 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.

> 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.

> 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.

> 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.

> 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.

> 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?

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


-- 
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