The ability to utilise a secondary overlay would make building package (and rebuilds) very swift for packages down the chain (not to mention stack updates). It will be important to ensure that it will only ever build using the same libraries as if it weren't used.
Static Concept
Support a few core overlays such as pkgconfig(gl), pkgconfig(Qt5Core), pkgconfig(gtk+-3.0). Much like how the current system works, where it's updated and stored in /var/lib/solbuild. It would have to be slightly different (and likely rebuilt when deps change to ensure it works exactly as it would without using it), with a mix between updates and rebuilds. Likely not great to have a 2nd overlay updated over a long period of time as deps will change.
Dynamic Concept
The two main benefits I can see from this 2nd overlay 'pinning' are for stack rebuilds and rebuilding a package multiple times to test configurations/patterns etc. A dynamic approach would be temporary where you can pin dep (or set of deps) while you rebuild a stack (where you aren't updating the deps), or make rebuilds faster as it doesn't have to install 200 packages each rebuild. It would still require some checks that the overlay is correct and could even be stored on /tmp as it's not meant to persist.
The ability to utilise a secondary overlay would make building package (and rebuilds) very swift for packages down the chain (not to mention stack updates). It will be important to ensure that it will only ever build using the same libraries as if it weren't used.
Static Concept
Support a few core overlays such as
pkgconfig(gl),pkgconfig(Qt5Core),pkgconfig(gtk+-3.0). Much like how the current system works, where it's updated and stored in/var/lib/solbuild. It would have to be slightly different (and likely rebuilt when deps change to ensure it works exactly as it would without using it), with a mix between updates and rebuilds. Likely not great to have a 2nd overlay updated over a long period of time as deps will change.Dynamic Concept
The two main benefits I can see from this 2nd overlay 'pinning' are for stack rebuilds and rebuilding a package multiple times to test configurations/patterns etc. A
dynamicapproach would be temporary where you can pin dep (or set of deps) while you rebuild a stack (where you aren't updating the deps), or make rebuilds faster as it doesn't have to install 200 packages each rebuild. It would still require some checks that the overlay is correct and could even be stored on /tmp as it's not meant to persist.