In D59304#1361038, @haraldei wrote:

Fix typo and tab-alignment

I would suggest always running portfmt after making any changes to Makefiles. This way, you would almost never worry about tabs/spaces, line wraps, etc.

Is there any specific reason for checking flavor twice? Putting USES + USE_XORG into same conditional would be nicer. Or just leaving USE_XORG as is because without USES=... xorg ... it's no-op.

In D56835#1321115, @michaelo wrote:

In D56835#1321082, @vsasjason_gmail.com wrote:

Will it help sshd to start without being indefinitely blocked by e.g. mysqld? That would be enough of a reason for me personally to switch to this thing immediately.

Can you elaborate on this?

Will it help sshd to start without being indefinitely blocked by e.g. mysqld? That would be enough of a reason for me personally to switch to this thing immediately.

In D56359#1290767, @laurent wrote:

@vsasjason_gmail.com you're right, it would be weird without the maintainer consent, but @adamw has given consent for this on the ports-developer mailing list. This work is to help him out.

[...] I'm not able to pay enough attention to FreeBSD, and I'm falling pretty rapidly behind.
For a few weeks, please do anything you feel is best with anything I normally maintain.

I mentioned that I would and he approved my involvement.

So yes, it's unusual, but not weird.

Am I the only one who sees this a bit weird to be committed without a single word from port maintainer and without reference to them in commit message? I don't think version updates fall into blanket approval category, and as a maintainer myself, would like to see no such surprises...

In D53924#1233441, @yasu wrote:

@vsasjason_gmail.com I know it but there is reason I don't use. When the source of patch is GitHub, content of the file sometimes changes with unknown reason and it causes checksum error. So I intentionally include patch file in ports tree.

In the diff below, I can see BROKEN_FreeBSD_13, however pushed version also includes BROKEN_FreeBSD_14 "because 14 requires libinotify from ports)". Can we unbreak fwupd on 14 by adding libinotify dep?

In D44487#1014651, @mat wrote:

but we want users to stop using ports and use packages

Excuse me for intervention with off topic, but this is extremely important to note, so please don't. The sole reason I use FreeBSD (I'm pretty sure not only me) is easy customization, including customization via ports framework.
However, it may be possible to consider packages after they will be built with:

1. Every possible OPTIONS combination.
2. Every possible -march.
3. Every possible optimization level and every possible combination of (at least) most widely used CFLAGS.
4. With each possible DEFAULT_VERSIONS value.
5. With any of local patches per user's request.

6..n. Each and every possible <name it>
But honestly, I don't think this can be realistically done.

In D44981#1025501, @diizzy wrote:

Do we still need to use the bundled version of HTTPLIB? https://github.com/equeim/tremotesf2/tree/2.6.2/src/3rdparty matches what we already have in ports, https://www.freshports.org/www/cpp-httplib/

Unfortunately, yes, we still need it. httplib 0.15 and above is broken on FreeBSD 13 due to old OpenSSL 1.

This is especially important after https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273514.

Could you please suggest Makefile line number for devel/git? I don't see that.

https://cgit.freebsd.org/ports/tree/devel/git/Makefile#n86

In D41975#957656, @andrew_tao173.riddles.org.uk wrote:

In D41975#957578, @vsasjason_gmail.com wrote:

So, initial thoughts on rework:

After carefully reading bsd.options.mk I came to following coclusions (but I may be wrong):

1. OPTIONS_FILE being crafted from <category>/<portname>, which means we can't really define any options inside flavors, but in root of Makefile only (to prevent overwriting OPTIONS_FILE by different flavors.

Take a look at devel/git or mail/postfix which override OPTIONS_FILE to allow different options for flavors.

So, initial thoughts on rework:

Unfortunately, diff isn't finished yet. Following removal from $4 an appropriate entry to $3 should be added as well.