imo, we don't want much granularity in source-build.
From maintainer perspective having separate packages adds additional complexity.
There should be a gain/rationale for that complexity.

The repositories that are used by source-build have proper release branches. We should be able to rely on that to have confidence re-built binaries only have minimal changes.

The repositories that are used by source-build have proper release branches.

From a Linux distro packaging perspective, they don't, IMO. The way the Microsoft build works, the shape of a repo's outputs on the release branch changes over time. What you get depends on what's being patched for the upcoming servicing version Microsoft plans to release. Forcing packages to build in the release branch puts us into territory that is unexplored by the Microsoft build and its tests.

We don't have to make extreme decisions based on this, but it's the root of the difference here.

I reworked it to focus on the recommended approach and moved the bulk of the doc (explaining why granularity is bad for source-build) into a different file. It should be much more readable now.

I moved the doc to fit in better with Documentation/planning/arcade-powered-source-build/README.md and added a small reference. This is something we should consider for 5.0--it would be bad to hit one of these pitfalls as we're getting the source-built SDK into more distros. I believe this should be incremental work after getting the initial source-build-in-arcade plan done. Once we merge the doc we can write up issues that reference it as appropriate.

@dseefeld PTAL