Upgrade key4hep fork of spack to v0.16.0

[vvolkl]

This will likely trigger a rebuild of many packages. Maybe good to take the opportunity to try to update root to the latest version?

[tmadlener]

Are there any known issues that would prevent us from using the latest root? E.g. the one that has been in the meeting minutes?

edit: I am speaking about the non-copyable collections that seem to appear with 6.22. Is that still relevant?

[vvolkl]

I remember something, but I have to look that one up. There was definitely an issue with pyroot recently - @gganis do you maybe know if this (and the issue Thomas is mentioning) has been fixed as of 6.22.04?

[gganis]

There isn't yet a universally accepted version of ROOT 6.22 . LHCb does not use it but Gaudi tests were failing until 6.22/04. ATLAS seems happy with 6.22/00, which is a bit of a mystery because they also use Gaudi. The latest patch 6.22/06 has still severe I/O issues which impact CMS. Apparently the latters have been understood and a new tag 6.22/08 is expected for the next days. However, whether the issue that you mention has been fixed, I cannot say for sure: was that reported with a JIRA or github ticket? If not, I doubt it was fixed, unless by chance as a positive side effect of other fixes. Better is to ask directly to the ROOT team or to give a quick try with 6.22/06 .

[vvolkl]

Thanks Gerri, that's good to know. I'm also not sure about the other issue. I think a good strategy would be to fix the testing with spack #89 and then just try to make an installation with 6.22.06? I think also having both root 6.20 and 6.22 in the stack would also be feasible, but we can only do that with a few packages, otherwise the combinatorics of version will explode ...

[tmadlener]

I don't remember enough about the other issue as well, but it could also be that that is really a fundamental root limitation and nothing that has been recently introduced.

I think giving it a go with 6.22/06 and see if we run into any problems is a good idea.

Maybe for similar decisions in the future we can check how large the differences in the stack are with two different root versions, i.e. how many packages would be installed twice. I am pretty sure for root this will be a lot, but for other packages the differences might be smaller and we could decide on an (almost) package-by-package level?

[vvolkl]

I am pretty sure for root this will be a lot

Indeed, it's a lot. There is a spack command to check this:

~$ spack dependents -i -t root
==> Dependents of root@6.20.04%gcc@8.3.0/oml2a44
-- linux-centos7-broadwell / gcc@8.3.0 --------------------------
3colgaf aidatt@0.10               qk4umcr key4hep-stack@2020-11-16
firnq4z cedviewer@1.17.1          djms74g key4hep-stack@2020-11-17
mrupzym cepcsw@master             llt7ibe kitrack@1.10
am63xg7 clicperformance@master    dravjfx kitrackmarlin@1.13
243jdfw clupatra@1.3              3sikjh7 lccd@1.5.0
zmiqrht conformaltracking@1.10    wor6r2s lcfiplus@0.10
2z7m5jb dd4hep@1.14.1             4ys5ncg lcfivertex@0.8
ojmvtse ddkaltest@1.6             ug2e6a3 lcgeo@0.16.6
bsy7lr4 ddmarlinpandora@0.11      eco6h75 lcio@2.15.3
ain5tuh delphes@3.4.3pre06        r5nf7v6 lctuple@1.12
sxtbzxm edm4hep@0.2.1             5fryijd lich@0.1
ibwlqs7 fcalclusterer@1.0.3       bn3g3gd marlin@1.17.0
ao2pyot fcc-edm@0.5.7             zcjbm3x marlindd4hep@0.6
jpeabfw fccsw@0.16                3ya4dfz marlinfastjet@0.5.2
aonbbtd forwardtracking@1.14      wqny2ja marlinkinfit@0.6
rlrculf garlic@3.1                hja7fph marlinpandora@3.0.1
da6k6w4 gaudi@35.0                xntemyg marlinreco@1.27
pl4wmg5 gear@1.9.0                ck2rkwi marlintrk@2.8
w7vclri generalbrokenlines@2.2.0  sguvgcf marlintrkprocessors@2.11
3mcnoaz ildperformance@1.8        u5bzjfe marlinutil@1.15.1
usf5yq5 k4fwcore@0.1.1            g2o4755 overlay@0.22.1
5tuywhl k4fwcore@0.2.0            zgcxehh pandoraanalysis@2.0.1
lkbgpsg k4fwcore@master           au6krsr physsim@0.4.1
jiqjcdr k4marlinwrapper@0.2.1     ycaakrq podio@0.12.0
7lt6t6t kaldet@1.14.1             thxasja raida@1.9.0
tz36xpk kaltest@2.5               sbxkg3s whizard@2.8.5

[vvolkl]

Tried out the new concretizer with key4hep-stack, apart from

https://github.com/spack/spack/pull/20088

seems to be working fine.

[vvolkl]

If we can wait for cepcsw & fccsw to be ready to use gaudiv35, we could also update python to the latest version.