Greg, > Am 11.02.2025 um 16:38 schrieb Greg Troxel <gdt%lexort.com@localhost>: > > oskar%fessel.org@localhost writes: > >>> 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“ > > But PHP_VERSION_DEFAULT will be set, because in lang/php/phpversion.mk: > > PHP_VERSION_DEFAULT?= 82 We are somewhat arguing in circles. PHP_VERSION_DEFAULT now gets set to something unexpected because the check is not there anymore. Which probably is a good thing for you. For me it is unexpected and thus not so good. No offense meant. > >>> 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. > > I mean "don't magically change PHP_VERSION_DEFAULT", just warn. > I see 'new requirement' as arguable. Yes, it worked to install 83 and > have pkgsrc pick it for new builds, but the documentation has always > described setting PHP_VERSION_DEFAULT. A pointer to the documentation _will_ be appreciated. I was working under the assumption by using „the source“ that PHP_VERSION_DEFAULT was not needed to be set explicitly because it was automagically set to the installed php version. > >> 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. > > make update, and make replace, often fail when there are changes to > package names, the set of installed files, and various other things. > The only thing that I see as reasonable for someome to do is: > > update the entire pksrc tree to a consistent checkout > run 'pkg_rolling-replace uv' > (so that mismatched and unsafe packages are rebuilt in order) As mentioned in my previous mail, this was exactly what failed. Because the need to update php83 before php82 could not be determined by pkg_rolling_replace. > > if you set PHP_VERSION_DEFAULT and did that, I suspect php83 would get > rebuilt first. the prerequisite was not fulfilled because i obviously did not set this. Because i failed to find the doc... > It still might not work, but it's the best I know how > to do. I would assume this works as expected. At least that it did for me after setting PHP_VERSION_DEFAULT� > We don't have a practice of special casing messages to deal > with make replace issues. (make update is similar; except that I view > it as so dangerous that I think nobody should ever use it) > >> It is. But since this is new as in „not necessary before“ there should be some hint on what to do. > > Sure, but lots of things change all the time, and we have doc/NEWS, > which should get an entry. That would have helped - instead i had to look into the mailing-list ;-) > We don't really have a culture of > accomodating every breaking change with code. fair enough. > >> So, my conclusion would really be „abort and give the appropriate hint >> - including new names and locations“. > > But the situation is not actually an error; having php83 installed and > 82 default is arguably probably not intended, but it would be a bug to > fail. I tend to disagree - it would be a bug to continue. And currently it aborts after having compiled everything ;-) Cheers Oskar
Attachment:
smime.p7s
Description: S/MIME cryptographic signature