Hello, Guix people and adjacencies! I want to talk about multi-source packages - let's call them bundles.
Taking a direct example, Arcan requires two checkouts: one from arcan itself, and other from (a heavily patched) openal. Currently we write this as: - source field: arcan source code itself - native-input: include openal source code - #:phases: include a phase to inject openal in arcan source tree I believe this approach to fetch bundles - roughly speaking, defining a master source and grafting the other ones in custom phases - is a bit pesky. It does not feel right to treat openal as a (native-) input. The natural way is to treat the bundle as a unified source. My idea is to expand the concept of source to deal with more complex [N1] source acquisition scenarios. We have two precedents for this, namely, snippets and .patch files [N2], although they are employed to modify or delete already existing files, not to add new ones. Since, for the most of time, these multi-source packages consist of merely reordering files, this bundle can be implemented like a restricted `copy-build-system`, a middle ground between this and `trivial-build-system` (since it does not feel right to run compilation tools inside source acquisition). For now I just want to register this idea for a mid-term future, but as soon as possible I want to show some code, despite not being a prolific Schemer. Best regards, -> Anderson N1 - Complex, here, is in the sense of "composed by two or more parts", not in the sense of "harder to understand". N2 - As a cursory note, Nixpkgs usually treats .patch application as a phase, not as a source modification (despite having an undocumented `applyPatches` functionality), while some fetchers have a parameter `postFetch`, similar in functionality to Guix snippets.
