"pkg updating" is unreliable

[T-Aoki]

Don't depend on metadata which is generated by humans (or AI ) but on actual system linking (ldd).

Another thing to mention is that pkg does NOT record BUILD_DEPENDS as dependencies.
This is fair from the point of view of local admins / users that use pkg to install pkgs. But insufficient from the maintainers' point of view.

And this behavior, unlike legacy bare-metal ports upgrading tools, could cause runtime issues that maintainers "cannot" notice when any of the components provided by any of BUILD_DEPENDS are actually needed in runtime, too.
Yes, within the environment that maintainers have, there are BUILD_DEPENDS installed, unless the maintainer uses only clean-room builders like poudriere to build ports and have no BUILD_DEPENDS installed.
But for old enough guys who exulted over the appearance of portupgrade like me, installing BUILD_DEPENDS regardless using directly or not is quite mature.

 

[T-Aoki]

In a sh script is a lot complicated, at least for me.

It would be because the very first developer of portupgrade chose ruby over sh to handle complicated dependency graph. And, if I recall correctly, ruby-haters started developing portmaster in sh.

 

[T-Aoki]

Forgot to mention.
One of what hidden dependencies harm would be noticed in cases like below.

1. Port C chanded its ABI (regardless API is kept backward compatible or not).
2. Port B is fixed (simple PORTREVISION bump is sufficient if API is kept backward compatible) to follow the change, but port A did nothing, as the maintainer of port A believes port C is 100% wrapped by port B at least what port A requires.
3. Port A starts crashing (or mis-behaving without crash). Or start failing build (link) if the new API of port C is NOT backward compatible.

If build failures happen, exp-run helps, but if not, exp-run cannot help at all, as exp-run means thoroughly build tests, not runtime tests.

 

[rwv37]

I don't know how useful this will be, but:

I've used Synth for years. It has always done a lot of scanning to figure out what is related to what, and how so. Plus, ever since FLAVOR became a thing, Synth has always taken even longer -- a loooooooooooong time -- "Scanning entire ports tree" while "Regenerating flavor index". I once asked the author if this was really necessary to do, or if perhaps there were some shortcuts that could be taken. I forget if he didn't give details or else he gave details that I didn't really understand, but in any case, I do remember that he responded, and the answer was "Yes, it is really necessary".

In general I have been very happy with Synth, and I trust it to do the right thing a whole lot more than I've ever trusted any other FreeBSD build mechanism I've used, going back literally decades (disclaimer: I've never used Poudriere... because I've been so satisfied with Synth). I base this on having run into a bunch of build problems over the years, and while I won't say that not a single one of them in the time I've been using Synth was because of Synth, I will say that the following is by far the most common thing in my experience (with the possible exception of problems that were simply due to my own misunderstanding of something):

1. I run into a build problem.
2. I post somewhere about it (like Bugzilla or here on the FreeBSD forums).
3. Someone blames it on Synth, without giving any real evidence.
4. I post about it on the Synth forums.
5. The Synth author convincingly demonstrates that it is not the fault of Synth, and is in fact the fault of <some-other-thing>.
6. I go back-and-forth between the two forums, essentially as a messenger.
7. Eventually everybody's on board with the idea that it is the fault of <some-other-thing>, not of Synth.
8. A fix is issued for <some-other-thing>.

So I guess what I'm trying to say is, maybe looking at the Synth source code can be used to get some good ideas for how this sort of thing is correctly done.