Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack.
Definitely not bulletproof but still IMHO more robust than "Lets just spray latest code from upstream without any review directly to production with a firehose!" that seems to be the norm.
That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.
The real issue for hooks in packaging formats like those is when you start adding third-party vendor repositories, e.g., Zoom, Google Chrome, Discord. None of the social enforcement mechanisms are there and the companies behind the products I just mentioned all have histories of abusing them.
That's why it's generally better to use Flatpak for things like that if your distro itself doesn't include them.
Not all packages come from the distro. People can and do enable external sources for software that isn't part of their OS.
¹ Annotation processors are a thing and somewhat similar to rust macros in function, but you need to set those up manually for each dependency, iirc.
But pulling a maven dependency DON'T run anything. You must download the repository that contains the POM.XML and run mvn with any goal that triggers the lifecycle.
Maven 4 aims to separate distribution and build poms. Currently, we generate distribution pom.xml for distribution using flatten plugin.
Got downvoted for saying it too. Don't let it discourage you.