Hej,
Takahiro Kambe <taca%NetBSD.org@localhost> writes:In message <rmijz9w658j.fsf%s1.lexort.com@localhost>
on Tue, 11 Feb 2025 07:22:20 -0500,
Greg Troxel <gdt%lexort.com@localhost> wrote:
It sounds like you are trying to have php detect if there is a version
installed, and essentially treat that as if the user had defined
PHP_VERSION_DEFAULT.
Yes.
I see this as adding a way to work around not setting
PHP_VERSION_DEFAULT, when really it's easy to set. And, it is
different from how python works.
lang/php?? packages were previously only one pacakge can be installed,
so it would help migration adding support for checking installed php.
Of course, it is transient technique.
I don't think it really helps, as it will cause more confusion than itsolves.
In the long term, I would agree. I would like to have php assume PHP_VERSION_DEFAULT is set to the PHP version installed, if there is only one and it is not explicitely defined elsewhere. On the other hand, how about:
If there is exactly one installed version and it does not match
PHP_VERSION_DEFAULT, emit a loud warning and sleep for 60s.
The Warning would be "PHP_VERSION_DEFAULT is not set, assuming <PHP_INSTALLED> is what you want to use as PHP_VERSION_DEFAULT“ Do not
attempt to do anythig different.
This I do not understand, what do you mean? Abort? Which would be the right way to handle a new requirement that did not exist before. Also it seems not to work with update logics for some people. cd <package to update> && make update then usually fails. There should be a meaningful error message, not only the conflict. But I don't really see this as a big problem; it's easy for people to
set PHP_VERSION_DEFAULT.
It is. But since this is new as in „not necessary before“ there should be some hint on what to do.
So, my conclusion would really be „abort and give the appropriate hint - including new names and locations“.
Cheers Oskar |