On Thu, Oct 11, 2001 at 09:28:28AM -0500, David Burgess wrote:
> Matthias Scheler wrote:
> > 
> > In article <3BC5A6F7.C1BCE223@neonramp.com>,
> >         David Burgess <burgess@neonramp.com> writes:
> > > I use horde/imp and need mysql and imap support built in.  Right now, I
> > > have to go in and uncomment/comment various options (many of which don't
> > > work) to get a working PHP4 that meets my needs.
> > 
> > I don't see a conflict with my suggestion. I only said that the stripped
> > PHP without any extensions should be in the "php4-base" package and that
> > all the extensions people expect to have are installed by the "php4"
> > meta package.
> 
> Neither do I.  I was simply voicing the opinion that a meta-package is
> not really needed.  I guess the only difference is that PHP4 as a base
> package with additional libraries is conceptually different than having
> a meta-package (which implies sub-packages).  
> 
> In fact, I think the only difference we have is whether or not a
> meta package would be an improvement.  It's only an opinion, and I'll
> support the method if that's chosen, but I find installation of PHP4
> as a program is a possibility.  If I don't need any additional
> functionality, the program is there and ready to use.  If I later
> identify an extension, I can add that by itself.  Since the components
> don't need to be installed at the same time, I don't think a meta
> package would add much.  In my view, the only thing that would 
> consistently be in the meta package is the basic PHP4 itself, which
> just seems to be an extra step.

I considered having a php4 meta-package but rejected it since the php4
meta-package would contain a confusing set of functionality.  To have the
updated php4 meta-package contain the same functionality as the current
in-tree php4 packge, the dependencies would look like:

	php4-base	bare php4 binary + PEAR installation
	php4-dba	DBM access
	php4-dbase	dBase access
	php4-filepro	FilePro access
	php4-gettext	gettext I18N API
	php4-sysvsem	SysV semaphore API
	php4-sysvshm	SysV shared memory API
	php4-wddx	Web Distributed Data Exchange API
	php4-xml	XML parser
	php4-yp		YP API
	php4-zlib	zlib compression API

Most of the functionality is just not useful for the typical PHP4 developer.
We have complaints about the current functionality of the php4 package, and
they would be no different if the php4 meta-package carried the same
functionality.

For a php4 meta-package to truly be useful, it should be like the suse_linux
meta-package where the meta-package is the superset of all of the
functionality that may be provided.  Then a user could simply "make install"
in www/phy4 and get the maximum functionality possible.  The only downside
to this is that about half of the shared modules depend on proprietary
libraries (Oracle, Impress, SyBase, etc.), so our php4 meta-package wouldn't
really contain all possible functionality; rather, it would have only the
"open-source" or "freely available" subset of that functionality.

Neither of the two scenarios really appealed to me.  It just seemed cleaner
to drop the bizarre extra functionality from the php4 package and focus on
using the new shared module architecture that became available with the
release of PHP4.

	Cheers,

	-- Johnny Lam <jlam@jgrind.org>