Subject: Re: CVS commit: pkgsrc/www/ap-php
To: Takahiro Kambe <firstname.lastname@example.org>
From: None <email@example.com>
Date: 11/05/2004 11:34:30
[moving to tech-pkg]
On Fri, Nov 05, 2004 at 07:24:21PM +0900, Takahiro Kambe wrote:
> In message <20041105105405.A16680@yoda.cubidou.net>
> on Fri, 5 Nov 2004 10:54:05 +0100,
> firstname.lastname@example.org wrote:
> > > > The similar problem exists binary packages for apache and apache2.
> > >
> > > this is different because they live in separate directories, so
> > > both are built in bulk builds.
> > I think what Kembe-san implied was that we don't get binary packages
> > of the PHP module for both apache and apache2.
> Maybe yes. For creating binary package for both apache and apache2,
> 1. Install apache and create ap-foo binary package.
> 2. Deinstall apache2 and create ap-foo binary package.
> Then, 1. will be overwritten by 2.
> If ap2-foo is provided separately or apache module for apache2 is
> always named as "ap2-xxx", this problem could be solved.
But it's unmanageable. In the end you get ap-php4, ap2-php4, ap-php5,
ap2-php5, and now consider you have the option of compiling in openssl
support, in case you want php to be able to do TLS, with say, a LDAP
server (it's not _that_ uncommon). Boom, 4 more packages.
In pkgsrc, we strongly push towards compilation from source instead of
binary packages, but we do (and _have_ to) ship binary packages with
release, and I even hope we'll start actually maintaining them in the
In my opinions, the set of binary packages should represent a default
configuration. As if to say, NetBSD ships with apache 1.3.x, with
PHP4 and so on. Of course, sometimes we want several different versions
of the same piece of software inside the tree, for various reasons, and
it results in several binary packages, but that doesn't mean it should
be the general rule.
As for the ap-php issue, I think having either one or two directories
doesn't matter much. PHP5 is rather young, and it doesn't make much
sense to have in a default configuration.
But I'd rather see the CONFLICTS line of apache2 fixed for ap-php :)