Support dumping the treefile with exact package versions being.

[adityashah1212]

I know we can dump the treefile with by resolving the includes before building the tree. But it would be really useful to be able to dump the treefile replacing each package with its exact name if not already specified. Doing this we can version control the dumped treefile and then use the treefile with the corresponding versions of treecompose-post.sh and repo files to regenerate the exact same build.

This will be very useful to people maintaining their own custom trees. I think this would the first step for #122.

[cgwalters]

Yeah, we can do this. There was recent discussion about this here:

https://mail.gnome.org/archives/ostree-list/2018-October/msg00005.html
(And then because mailman breaks threading across month boundaries, continues here: https://mail.gnome.org/archives/ostree-list/2018-November/msg00000.html )

[dustymabe]

@cgwalters - would you say this is a medium difficulty task?

[miabbott]

In addition to this, being able to know which repo the package came from as well would be useful.

[cgwalters]

Strawman: A new compose tree --write-lockfile=manifest.lock argument, and a new compose tree --lockfile=manifest.lock to read it back for subsequent invocations. It outputs YAML of the form:

packages:
  - fedora:
    - ["glibc-2.28-26.fc29.x86_64", "11345a868e4501067929158e0ca5f91b83243cd65c85df92062b58cb7258b4bb"]
    ...
  - fedora-updates:
    - ["kernel-4.19.13-300.fc29.x86_64", "59fd74cef04f7369180573d00b794455fc994c501d52bb039e2b4fec2b334e80"]
    - ["systemd-239-7.git3bf819c.fc29.x86_64", "05909d0af94782c7d1a6e8da03e86178221f500935bcb541716e3a38966d58d1"]
    ...

Basically a list of repos, each of which contains an exact NEVRA plus the repodata sha256sum (not the rpm checksum).

When provided with --lockfile as input we pass that info to the depsolver; I am not sure if there's a way we can say to libsolv "give us the package with this repodata checksum" but at least we can verify it after.

Probably the sanest is that if --write-lockfile is specified it acts just like coreos-assembler fetch i.e. we don't actually do a compose, and support --touch-if-changed so higher level logic can react to that.

[cgwalters]

(Also worthwhile to look at Rust's Cargo.toml and Cargo.lock for inspiration)