Report version number when running rpm-ostree compose tree

[nullr0ute]

When running a compose tree within other tools such as pungi rpm-ostree doesn't output any details of the version that's running. It would be useful to enable quick and easier debug if it output a line with version, and possibly some other pertinent information (no I'm not sure what that might be) to aid debug.

An example extract of the beginning of a compose currently looks like this:

COMMAND: rpm-ostree compose tree --repo=/mnt/koji/compose/iot/repo/ --write-commitid-to=/mnt/koji/compose/iot/Fedora-IoT-30-20180911.0/logs/x86_64/IoT/ostree-3/commitid.log --add-metadata-string=version=30.20180911.0 /mnt/koji/compose/iot/Fedora-IoT-30-20180911.0/work/ostree-3/config_repo/fedora-iot.json
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Previous commit: 34a11d32c09d0827cded3e868e638866353e33469622442c5fabb4d5cc11e259
Enabled rpm-md repositories: repo-0
Updating metadata for 'repo-0': 100%
rpm-md repo 'repo-0'; generated: 2018-09-10 07:40:42
Importing metadata 100%
Resolving dependencies... done
Installing 479 packages:

[cgwalters]

A patch to do that would probably be fewer lines than this reply, but...I lean a little bit towards having higher level tools do stuff like that. It should also be an easy patch for e.g. pungi right?

Or for instance, a patch to our new coreos-assembler project.

[nullr0ute]

Why would pungi report the version of a tool that it's not in control off, that makes no sense what so ever, a line in the output of the tool would be useful especially when it generally isn't run interactively. I had to dig through a whole bunch of different log files this morning to work out the version of rpm-ostree.

[dustymabe]

I sit on both sides of this fence. for peter's particular case it's not too hard to find the version by looking at what rpm got installed in the root.log (log here) from the koji task.

on the other hand it can be useful in a build system to have output (log output) that gives you this information more freely right at the top of the log where people are going to look first. Another particular example of this I find useful is anaconda where the first statement in the log is something like:

09:57:47,421 INF main: /sbin/anaconda 30.2-1.fc30

[nullr0ute]

@dustymabe you're right it's not hard, but it's time consuming where most tools like this would report it because it's useful information.

Ultimately I have no particular urge to bike shed. I thought it is a useful piece of information to have reported by the tool itself. If you don't wish to be helpful to your users well ¯_(ツ)_/¯

[dustymabe]

@cgwalters - a PR for something like this would be a good "first issue" for someone learning the project. Would you accept a patch if a newcomer submitted one?

[cgwalters]

Why would pungi report the version of a tool that it's not in control off,

Pungi today directly invokes rpm-ostree right? It's certainly in control.

I thought it is a useful piece of information to have reported by the tool itself. If you don't wish to be helpful to your users well ¯_(ツ)_/¯

Hey now, let's be civil here. I think my initial response here was - note I'm not saying no.

One other important piece of background here is that today, rpm-ostree doesn't have any kind of split between client and server side compose tooling, and I regret that now. Part of working on the new coreos-assembler project is to implicitly create that split. We have far more freedom to depend on whatever tooling we want in a separate project. Particularly for rojig we depend on e.g. createrepo_c, rpm-build and lots of other stuff that we clearly don't want to ship to clients.

[cgwalters]

Would you accept a patch if a newcomer submitted one?

Sure.