1. 9. 2015 v 14:47, Greg Troxel <gdt%ir.bbn.com@localhost>:
>
> 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.
I had the latter in mind and only the case of true PHP apps that are not built or linked against any kind of PHP package. E.g. roundcube or magento are just heaps of PHP scripts that do not care about PHP versions, and the only real difference between php55-roundcube and php56-roundcube packages would be the dependency patterns.
At this point a `pkgin in roundcube` forces PHP 5.5 on the user, which is limiting for no particular reason. In my ideal scenario the end user would be able to decide he wants to use roundcube and PHP 5.6 and pkgsrc would build the dependency bridge at package install time.
-F
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail