sidbelbase What you do for your own use is up to you. We have a different set of standards and expectations for packages in the Solus repos.
sidbelbase but you could always check the log later if it went right or not.
It's not a matter of whether a package builds. You need to audit it for a lot of different things. Some examples:
- New features that need to be enabled. Most build systems will happily ignore these, so a human needs to actually check.
- Missing optional dependencies. Again, build systems are designed to carry on, not to ask if you want to enable something.
- Features that are being deprecated in the future. Sometimes things get removed from software and need to be planned for a fair bit of time in advance.
- ABI changes If the package is a library, there's always a chance that symbols are added or removed from the ABI. If they are added, you may want to recompile other things to take advantage of the new symbols. If they are removed, you may need to recompile other things to prevent them from using a non-existent symbol.
- Changes to the default config It's not uncommon for a project to change their defaults and for a package to need to revert the change for it to continue as users expect.
Note that none of those changes are self-evident without diving through the build log, reading changelogs, or using tools like abi-wizard to deeply inspect binaries.
Then there's also things that are unrelated to package updates:
- CVEs When there's a security vulnerability, you may need to patch it long before a new release is available. Not every project is proactive about these fixes or able to release whenever they feel like. Patching is essential.
- Rebuilds When dependencies change, rebuilds might be necessary for ABI changes, for example.
- Better integration with the host OS This might be adding a missing systemd Unit for any number of things like tmpfiles or sysusers. Maybe a missing .desktop file or maybe just overriding the default configs.
