Re: Prefixing PHP packages with ${PHP_PKG_PREFIX}

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Mon, Aug 31, 2015 at 10:45:42PM +0200, Filip Hajny wrote:
 > For things like roundcube and magento, i.e. software that doesn?t
 > built against a particular version really and is generally happy to
 > just use one, I?d love to see dependencies defined in the
 > {php54,php55,php56}-dom-[0-9]* kind of pattern.

Historically the practice has been that modules (that is, things that
other software can depend on and import) have been prefixed, and
applications (things that just use the interpreter) have not.

(It is roughly the same distinction as we make using buildlink for
libraries one can compile against and not for just things that get
executed.)

This practice preserves the principle of least surprise for the names
of applications (which are usually what one looks for by name) -- e.g.
if you want to use roundcube you don't have to somehow know you should
stuff "php54-" in front of the name. Similarly, to use youtube-dl you
don't need to somehow know to stick "py27-" in front, and to use
spamassassin you don't need to know to insert "p5-".

I think this practice should continue: that is, don't insert
PHP_PACKAGE_PREFIX in front of the names of applications like
roundcube. The predictability of naming is more important (especially
for binary package users) than a workaround for temporary build
problems. IMO.

AIUI the problem is that if you're trying to use e.g. both roundcube
and wordpress, and one of them doesn't work with PHP_VERSION_DEFAULT,
the binary packages will depend on different php versions and then
can't be installed at the same time. If this is really a serious issue
(particularly given that packages written in interpreted languages are
usually trivial to "build" locally) we should probably pursue some
more general solution.

(How hard would it be to forcibly install each php version in its own
subtree of $LOCALBASE?)

(Failing that, one of the big things we don't have is a way to have
binary packages built with different groups of settings in the same
package repository. This is mostly a naming problem; if somebody
solved it, then we could just build php applications for all php
versions without compromising the package name.)

(The cheesy way would be to insert the name prefix on every php
application and then generate a corresponding meta-package without the
prefix. Mercurial works this way in pythonland, because it's an
application but also installs a Python library.)

 > We lack a binary
 > package world alternative to PHP_VERSION_DEFAULT (or a dependency
 > evaluation logic) for this to work though - one that would first
 > look at an existing PHP base package, then consider a preferred
 > version based on ENV, then fall back to the latest available, then
 > go back to direct dependencies required and evaluate.
 > 
 > Do you feel this is something worth working on?

Yes. I think ultimately this is part of having binary packages built
with different groups of settings -- otherwise there's not really
anything to resolve. Unless you build in magic knowledge of
*_PACKAGE_PREFIX and that's much the same thing except the wrong way
to do it. :-/

-- 
David A. Holland
dholland%netbsd.org@localhost