lib/bootconfig-parser: Always include deployment index in BLS title

[martinezjavier]

If there are different deployments for the same commit version, the BLS
snippets will have the same title fields (but different version fields):

$ grep title *
ostree-1-testos.conf:title TestOS 42 20190902.0 (ostree)
ostree-2-testos.conf:title TestOS 42 20190902.0 (ostree)
ostree-3-testos.conf:title TestOS 42 20190902.0 (ostree)

But bootloaders could expect the title field to be unique for BLS files.
For example, the zipl bootloader used in the s390x architecture uses the
field to name the boot sections that are created from the BLS snippets.

So two BLS snippets having the same title would lead to zipl failing to
create the IPL boot sections because they would have duplicated names:

$ zipl
Using config file '/etc/zipl.conf'
Using BLS config file '/boot/loader/entries/ostree-3-testos.conf'
Using BLS config file '/boot/loader/entries/ostree-2-testos.conf'
Using BLS config file '/boot/loader/entries/ostree-1-testos.conf'
Error: Config file '/etc/zipl.conf': Line 0: section name 'TestOS 42 20190902.0 (ostree)' already specified

Avoid this by always including the deployment index along with the commit
version in the title field, so this will be unique even if there are BLS
files for deployments that use the same commit version:

$ grep title *
ostree-1-testos.conf:title TestOS 42 20190902.0 (ostree:2)
ostree-2-testos.conf:title TestOS 42 20190902.0 (ostree:1)
ostree-3-testos.conf:title TestOS 42 20190902.0 (ostree:0)

$ zipl
Using config file '/etc/zipl.conf'
Using BLS config file '/boot/loader/entries/ostree-3-testos.conf'
Using BLS config file '/boot/loader/entries/ostree-2-testos.conf'
Using BLS config file '/boot/loader/entries/ostree-1-testos.conf'
Building bootmap in '/boot'
Building menu 'zipl-automatic-menu'
Adding #1: IPL section 'TestOS 42 20190902.0 (ostree:0)' (default)
Adding #2: IPL section 'TestOS 42 20190902.0 (ostree:1)'
Adding #3: IPL section 'TestOS 42 20190902.0 (ostree:2)'
Preparing boot device: dasda (0120).
Done.

[cgwalters]

@rh-atomic-bot r+ 7986c73

[rh-atomic-bot]

⚡ Test exempted: pull fully rebased and already tested.

[cgwalters]

Debated a little bit with myself whether we should e.g. only do this if it's nonzero, but eh.

I think at some point we want to allow more control over this for e.g. rpm-ostree; more generally in any case where you have the same base OS version deployed multiple times. It'd be nice to have maybe even something like (ostree +7) for 7 layered packages or so?

But this is quick and easy for now, thanks for the patch!

[tpopela]

Debated a little bit with myself whether we should e.g. only do this if it's nonzero, but eh.

I think at some point we want to allow more control over this for e.g. rpm-ostree; more generally in any case where you have the same base OS version deployed multiple times. It'd be nice to have maybe even something like (ostree +7) for 7 layered packages or so?

What you are suggesting would be really helpful. Just for clarity it's being tracked as coreos/rpm-ostree#1239.

[cgwalters]

Ah, there it is. I'd searched for that issue but couldn't find it. And now I realize I was looking for author:mclasen and not author:matthiasclasen...