Subject: Re: ap-php4 depends on apache 1.3
To: Zafer Aydogan <firstname.lastname@example.org>
From: Quentin Garnier <email@example.com>
Date: 01/16/2006 14:48:47
Content-Type: text/plain; charset=us-ascii
On Sun, Jan 15, 2006 at 11:38:22PM +0100, Zafer Aydogan wrote:
> The Binary Package ap-php-4.4.1nb3.tgz depends on Apache 1.3.x.
> But when installing via pkgsrc it decides whether apache 1.3 or apache
> 2 is installed and builds the correct module for apache 1 or 2.
> But when installing as a binary, it tries to install apache1.3
> although apache2 is installed.
> I think it should be possible to install a php module for apache2 as a
> binary aswell.
> There is currently no way to install the PHP Module for Apache 2 as a
> binary package.
> Separate Packages could be a solution. For example ap-php4 and ap2-php4.
Currently, the binary distribution provided on TNF's FTP server is not
globally managed: packages maintainer are free of their choices as for
the default version (which is the version we distribute).
pkgsrc has that quality over _all_ binary distribution systems is that
it can allow a lot of different options for the user, as long as the
user uses the source package.
What you see as missing is an option you want to use. This is highly
debatable: some people will not want apache 2 for similar reasons you
don't want apache 1.
A binary distribution cannot be optimal for everybody's use. Almost
all major Linux distributions suffer from that issue: for a given
package, either it doesn't include the option you want, or it depends
on dozens of packages you'd rather not have on your system. In my
experience this is much more frustrating than what you are experiencing.
However, I think we could still improve things a bit. While I don't
know a lot about OpenBSD's flavours, I think we could have something
that I'd tend to name the same way.
Currently, we only have one set of default options, that's
PKG_SUGGESTED_OPTIONS. One way of improving things would be to have
several sets of options. Then we would have binary packages named
after that "flavour" (I'm not giving any code here; there are many
ways of doing that).
There is a huge drawback to that: it will increase duration of bulk
builds, potentially by a lot of time, because packages subject to such
a feature are usually the bigger ones. It will also increase the size
of a binary distribution. I'm really not sure we currently have the
resources for both those problems.
Quentin Garnier - firstname.lastname@example.org - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----