Filip Hajny <filip%joyent.com@localhost> writes:
> 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. 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?
I'm not quite sure which of two things you are proposing:
given a package with a set of acceptable php versions, and a system
with a default and an installed set, pick a version that's within the
overlap and then build a package which is hard-coded to that version
build a package that can depend/work at runtime with any of several
versions
For the first, I'm generally in favor of as little magic as possible,
along the lines of using the configured default, unless the package's
declared set does not include the default, in which case I'd pick the
highest one the package supports.
The second seems tricky, in terms of embedded paths, and configure
tests, and we haven't really gone down that path much for packages that
install things to different paths. If you do want to do this it would be
nice to write up the design for review first as I think others will have
some useful comments on the details.
Attachment:
pgpjPMCvTIuxM.pgp
Description: PGP signature