Rewrite to match changes to logic, and extend some parts slightly.

Also PORTREVISION should not be changed if there are no functional changes, since you'd just be forcing rebuilds/updates of every dependent port for no reason.

5.3.6 is imminent, if there's any point at all in doing this cosmetic change then it could at least be folded into that.

In D14709#571480, @russ.haley_gmail.com wrote:

Ah, I thought I had mucked something. Shall I restore them?

I still think it's nuts to install multiple luarocks installations when the big feature of luarocks 3.x was the ability to handle multiple lua versions. But I'll withdraw my objection.

In D14709#571428, @russ.haley_gmail.com wrote:

• Removed non-relevant ports packages included by mistake

In D25784#571185, @russ.haley_gmail.com wrote:

In D25784#570925, @andrew_tao173.riddles.org.uk wrote:

What's the justification for adding flavors, given that one luarocks install is supposed to be able to manage multiple lua versions?

When I try installing LuaRocks from ports/pkg I always get 5.2, regardless of the installed version of lua (due to the FreeBSD default Lua version of 5.2). The FreeBSD default means Luarocks is also configured for Lua 5.2 and the executable/script is called luarocks52. Perhaps I've done something wrong and there is an easier way around that, but this seems to perfectly fit the use case for flavors?

I think, in fact, the only useful change would be to install config files for every supported lua version rather than just the default one.

What's the justification for adding flavors, given that one luarocks install is supposed to be able to manage multiple lua versions?

Updates to address comments.

Lua 5.4.0 is now released, so this is now a blocking issue for the lua54 port.

Move to an earlier place in processing (in fact the earliest possible place, just after PKGORIGIN is set).

In D22189#557452, @mat wrote:

Is it possible to have the flavors not conflict with each other? Like, the full flavor only install the bits that are enabled by the options.

I think this addresses all of my points.

In D25038#553896, @kevans wrote:

Will we be able to wrap this up before the conclusion of the 11.4 release cycle, or is this suddenly going to get bumped into SA status?

It's also not clear to me if we're now-satisfied with the changes, including stack alignment.

In D25038#551788, @kevans wrote:

In D25038#551786, @andrew_tao173.riddles.org.uk wrote:

While at it, would it be worth adding a check that the stack size is at least MINSIGSTKSZ + PATH_MAX ?

When you say 'adding a check', are you proposing a static assert that PSPAWN_STACK_ALIGNMENT at least fits MINSIGSTKSZ + PATH_MAX , or runtime check just before calling rfork_thread()?

Adding an EINVAL return to rfork_thread will cause this code to fall through to the "use vfork instead" logic, hiding the error in unexpected ways.

Discussion point: this implementation converts the variable name to upper case for consistency with the way that port option_VARS works. But there are some cases where one might want to set a mixed-case name (such as CFLAGS.arch), so maybe it shouldn't do that and just use the case as written?

Incidentally, in case it's not obvious, if my addition is moved to before the inclusion of bsd.default-versions.mk then it remains entirely possible to do

In D24324#544139, @adamw wrote:

I really like the idea of being able to simply and cleanly set vars for specific ports from /etc/make.conf. I think the choice of variable naming is exactly right here, and the implementation is clean and simple.

However, I am 100% with @mat here that bsd.default-versions.mk is the wrong place for this. The idea is that the things defined in there choose one from a list of conflicting options. If every port is built with ssl=openssl and one port is overridden with ssl=libressl, then it will be impossible to install that port without uninstalling everything else. I can't think of a scenario where any default version should be overridden.

Can you implement this somewhere else, so that default versions are preserved?

Lua 5.4.0 is planned for release next week, it would be nice to have this resolved sometime reasonably soon.

In D24324#543789, @mat wrote:

What difference is there from having either a Makefile.local with whatever you need in the port's directory, or using what everyone has been using for decades:

.if ${.CURDIR:M*/lang/rust*}
DISABLE_MAKE_JOBS=yes
.endif

Discussion opened upstream at http://mm.icann.org/pipermail/tz/2020-May/028970.html

I don't think there's a great deal of merit in adding this change just to pander to broken apps (it's not like fstat is hard), but I do think it's actually an improvement from a UX perspective (who amongst us has not been annoyed at some point by cat'ing a directory by mistake).

I just noticed that the diff here had been replaced by the one from the first commit, so I'm re-uploading the diff of just the uncommitted part for ease of further review.

This needs to stay on hold pending the change to the version selection logic discussed on D14709.

Others have supported the "closest to default" rule, so I'll put up a separate patch for that.

In D14709#538596, @antoine wrote:

In D14709#538595, @andrew_tao173.riddles.org.uk wrote:

In D14709#538585, @antoine wrote:

In my opinion, it's a bug in Mk/Uses/lua.mk that USES=lua:53+ chooses lua 5.4 over 5.3

What alternative logic do you suggest?

Maybe chose the closest from default version that fits the constraints

In D14709#538585, @antoine wrote:

In my opinion, it's a bug in Mk/Uses/lua.mk that USES=lua:53+ chooses lua 5.4 over 5.3

Change the two ports that declared themselves lua:53+ to just lua:53, since they don't seem to respond sanely to attempts to force configuration with 5.4 using environment vars.

Add a note about avoiding use of XY+ version specifications

Should work with patch -p1

Test results: adding support for 5.4 causes only two ports (archivers/urbackup-server and x11-toolkits/termit) to switch from lua 5.3 to 5.4 when LUA_DEFAULT is 5.2. (They would not switch if the default were 5.3; both are declared as lua:53+, and the default version is chosen if it is in range, otherwise the latest available version in the range.)

Update to lua 5.4.0-rc1

This should have been fixed in bsd.sites.mk, which would unbreak a bunch of other ports too.

In D24306#535952, @ngie wrote:

new installs *should* be using the new timezone mappings, so the need for the old ones will die off over time.

In D24306#535757, @delphij wrote:

does not mean we should remove these links.

To explain the full context of the original link:

I think this change is a bad idea and should be reverted. (The "backward" file in the IANA db is for ancient compatibility, and FreeBSD has been excluding it by default since 1994 as far as I can tell; this is not the time to be adding it back.)

Fix rebase error that caused a deleted file (lua51-iconv/Makefile) to be revived due to a conflicting trunk commit.

Ugh, previous diff was reversed. Fix.

Rebase. Un-deprecate lua-iconv, because the only thing keeping it broken is the failure to update bsd.sites.mk in a timely manner.

Rebase. Fix most of mat's requests. Make the usage of LUA_VER / LUA_VER_STR a bit more consistent. Allow for the option of lua:build,run if needed.

From discussion just after I posted this, it sounds like math/plplot actually needs a PORTREVISION bump not included in this patch.

Rebase and include fixes.

This one includes the changes to the actual ports, plus fixes to a few issues in lua.mk.

Fix bug in non-LOGIN_CAP case. Update manpage.

In D21481#516072, @kevans wrote:

These should have all been committed -- because I didn't want to trigger a close with an incomplete diff, I did not put in the proper tag to close it. Please do close it out if you're satisfied via "Add Action" > "Close Revision" under the diff.

This got brought up _again_ on IRC, but this time someone (sphex) came up with an actually interesting idea: what if there were a login.conf variable, e.g. cron.setpath, which if set caused cron(8) to respect the PATH from the login class if not overridden in the crontab file? This doesn't seem to hard to implement.

Rebase and add docs.

env.1 manpage will need changes, want me to add those?

Any breakage is probably my fault - I need to pick this one up again and work on it some more.

Fix unneeded dependency on guile-cairo when CAIRO option is off.

Add flavors (full/lite).

Add build dependency on gettext-tools, to get some stuff (gnulib's lib-link.m4) that actually has nothing to do with gettext :-(

Ugh, build does break for some option combinations due to hidden dependency on gettext-tools (for aclocal/lib-link.m4). Will post new patch after next round of tests.

No, this change is wrong if LUA_PREFIX is something different from /usr/local, since in that case luaconf.h does indeed get modified.

In D14709#483062, @russ.haley_gmail.com wrote:

In D14709#483029, @andrew_tao173.riddles.org.uk wrote:

Looks like Roberto snuck some hardcoded -Os options into the makefile, we need to either patch those back out or think of something else to do with them.

You should ask about that on the mailing list. -O2 is specified twice, as well as -Os. Which option does the compiler take?

Looks like Roberto snuck some hardcoded -Os options into the makefile, we need to either patch those back out or think of something else to do with them.

You seem to have duplicated a patch? There should be no patch for lua.c other than the extra-patch-libedit-dl one.

• When the ASSERT option is selected, the extra-patch-assert file fails to apply cleanly. I tried to port it over but I there has been a change to lgc.c and I don't know enough about lgc to apply the patch (Help Andrew?).

Style fixes. Rebase.

Now that a 5.4.0-beta release has been made, and there are signs that features are actually stabilizing (there have been many changes since work2), perhaps we could pick this up again. The distinfo needs an update of course.

Further proposal (the patch doesn't do this yet): cron should not override PATH when reading a user crontab; whether it should use the user's path, or daemon's path, rather than the hardcoded default when processing the system crontab is a more open question.

I've been pondering whether limits(1) also needs an option to pick up the environment from the login class, or whether that's better addressed in rc.subr for the case of servicename_class="x" settings.

In D21402#467883, @pkubaj wrote:

In D21402#467690, @andrew_tao173.riddles.org.uk wrote:

Why isn't this just CFLAGS+=-fPIC ?

Because e.g. powerpc64 doesn't need it.

Why isn't this just CFLAGS+=-fPIC ?