Dynamically load patch series from fetched repositories.

Hi everyone. I am looking for a way to use patches in recipes without 
adding them to layers and then mentioning directly in SRC_URI. An 
example workflow would be:

1. Fetch a repository that is added in SRC_URI, using either git or 
other available methods.
2. Check out the specific head in the repository  (a branch or a commit).
3. Let do_fetch or do_patch search for either a "series" file or a list 
of patches in the repository.
4. Apply the patches.

The only problem I see in the proposed flow is the 3rd step. Some 
repositories may contain patches that could be applied to different 
tools or packages. And a recipe that is responsible for a package A can 
try to apply patches for a package B that is being stored in the same 
repository with patches. Hence, the 3rd step should be restricted 
somehow. An example could be a variable that will point out the place in 
the repository with patches where the recipe for package A should search 
patches. The variable can utilize overrides to customize patch queues 
further.

An example of the repository with patches can be found here: 
https://github.com/Dasharo/dasharo-pq/tree/flashrom-testing/flashrom . 
The idea here is not to copy and paste the huge amount of patches into 
different build systems, but to have a single place where all patches 
are added and maintained. Other pros for this solution:

* Clear separation of concerns: Build systems remain focused on 
configuration and integration logic, while patch content and maintenance 
are handled elsewhere. This keeps repositories smaller, cleaner, and 
easier to reason about.
* Single source of truth: A centralized patch repository establishes a 
clear, authoritative source for all modifications. This avoids ambiguity 
about which patch version is “correct” and prevents subtle divergences 
that can arise when the same patch is copied and slightly adjusted 
across multiple build systems.
* Simplified updates and backports: Bug fixes, improvements, or rebases 
of patches need to be done only once. Downstream users automatically 
benefit from updates without having to manually replicate changes or 
re-evaluate multiple patch copies.
* Reduced review and validation effort: Code review, testing, and 
validation can focus on a single patch location. This is especially 
valuable for large or security-sensitive patch sets, where duplicated 
reviews across repositories would waste time and increase the chance of 
missed issues.
* Improved traceability and auditing: A centralized repository provides 
a complete history of why and when patches were introduced, modified, or 
dropped. This is important for audits, compliance requirements, and 
post-mortem analyses, especially in firmware or low-level tooling contexts.
* Lower risk during upstream transitions: When patches are eventually 
upstreamed or dropped due to new upstream releases, central management 
ensures that all consumers transition in lockstep. This avoids 
situations where some build systems still rely on patches that are no 
longer needed, or worse: no longer compatible.

Let me know if you have a better proposition for the implementation flow 
I have presented, or if I have missed some already existing technology 
in the Yocto Project. Either my colleagues or I would be eager to 
contribute such a feature to the project.

-- 
Best regards, Daniil Klimuk.
3mdeb Zarhus Team Leader.
https://3mdeb.com | @3mdeb_com