> a. keep the file /manifest as it is today; and add > options to convert it to regular manifests and channels. > b. improve the format of this file to obtain consistent manifests. > > and c. improve what the --manifest option accepts. Agreed. > From my perspective, the option b. is a better path because it remove > layers and complexity. I thought you meant "do all 3 options". How would option b. alone be enough? >> Should we not change the format, should we add a command line option to >> convert manifest to "manifest specifications" (those that work with >> `-manifest')? How do we include the provenance in manifest specifications? > > The provenance of what? How do we include the "provenance" field from manifest into "manifest specifications"? > Basically an entry looks like: > > --8<---------------cut here---------------start------------->8--- > ("diffoscope" > "131" > "out" > "/gnu/store/h8zr4rxhvpikv9p07kdjkf2dsrja35wm-diffoscope-131" > (propagated-inputs ()) > (search-paths ()) > (properties > (provenance > (repository > (version 0) > (url "https://git.savannah.gnu.org/git/guix.git") > (branch "master") > (commit > "b5d4d5b9bcf267fddd02fcc14b88eac0bebf979f"))))) > --8<---------------cut here---------------end--------------->8--- The above is not very human friendly. Each entry should be something like plist with default values, so that the user does not have to write "out" every time. What about this: ("diffoscope" :version "131" :output "doc" ; "out" is the default. :provenance (repository ...)) Questions: - Do manifests really need the store path? - Same question about propagated-inputs. Aren't they already encoded in the package definition? Why repeating them here? -- Pierre Neidhardt https://ambrevar.xyz/