Re: Build failure tooling improvements

[Rob Whitlock <rwhitlock22%gmail.com@localhost>]

> On Mar 20, 2025, at 1:29 PM, Jonathan Perkin <jperkin%pkgsrc.org@localhost> wrote:
> 
> It's been encouraging to see some of the proposals recently to improve quality.  Something I've obviously been very passionate about for a long time.
> 
> In the past I've done a lot of work, whether that's daily bulk builds across multiple operating systems, the CI system, scan failure mails, custom bulk builds, lots of additional checks, etc, but they haven't always been well received or used as I'd hoped, which has obviously led to some frustration on both sides.
> 
> So, how about a different approach.  What would you like me to work on?  What features would you like to see, and would actively use?  What is your ideal workflow?  What would it take for your workflow to include cross-platform checks prior to commit?  What resources do you need to help ensure each individual commit is as high-quality as possible?
> 
> I want to build systems and tooling that will help improve pkgsrc quality, but they have to actually be used, with a reasonable expectation that failures will be acted upon.  If we can agree on it, I'll build it.
> 
> I'm in the very fortunate position where I'm employed to work pretty much full-time on pkgsrc, and I'd much rather that time was spent on tooling that will be used by everyone and improves pkgsrc for all.
> 
> It's likely that there will be too many differing opinions to come up with a golden path that suits everyone for every commit, but I wonder if we might get to the point where we at least have a pmc-enforced path for the more critical parts of the tree.
> 
> Thanks,
> 
> -- 
> Jonathan Perkin                    pkgsrc.smartos.org
> Open Source Complete Cloud   www.tritondatacenter.com

I'd like to be able to keep work dirs around between pkgsrc tree updates, and have the updating rebuilds of packages only build the things that have changed. This could be kind of like how you can update a NetBSD system from source by looking in UPDATING, deleting some of the build products in the work dir, and use MKUPDATE=yes or build.sh -u. I realize that this might be challenging to implement and might even require some coordination from various upstreams to get them to track and publish the information that lets you delete only some of the build products (or maybe we could derive that automatically somehow), but I think the performance increase for people updating from source would be so drastic that maybe we ought to consider it anyway. Consistency between regular from-scratch builds and workdir-kept builds could be largely ensured by having reproducible builds from both and then comparing them for equivalence.