I'm just wondering, how the mqtt5 conflicts, but more in general a "sub-package" availability is modelled?

@hainest your input on this question would be valuable! I wasn't quite sure about the various (seemingly) ad-hoc conflicts and methods of enabling/disabling subpackages, so I only included the on that seems to be used the most, namely

        if not spec.satisfies("@1.88.0:"):
            with_libs.discard("mqtt5")

but I certainly wouldn't mind modeling that as a conflict instead. I just didn't want to start changing that for all the subpackages as that would be a significantly bigger change.

Unrelated, but do the build failures here look familiar to anyone: https://gitlab.spack.io/spack/spack/-/jobs/16344209#L423? A number of packages are failing with

error while loading shared libraries: libunwind.so.8: cannot open shared object file: No such file or directory

which sounds unrelated enough that it could be a failure that's already on develop, but I wouldn't be surprised if the new version of boost somehow triggers an error like that.

I'm just wondering, how the mqtt5 conflicts, but more in general a "sub-package" availability is modelled?

I see

spack/var/spack/repos/builtin/packages/boost/package.py

Lines 156 to 157 in bef1397

	# Add any extra requirements for specific
	all_libs_opts = {"charconv": {"when": "@1.85.0:"}, "cobalt": {"when": "@1.84.0:"}}

and

spack/var/spack/repos/builtin/packages/boost/package.py

Lines 296 to 297 in bef1397

	# Container's Extended Allocators were not added until 1.56.0
	conflicts("+container", when="@:1.55")

I would expect mqtt5 added somehow there too, no? am I missing something?

Conflicts are ad-hoc right now. If you have a specific conflict you need to resolve, please submit an issue here and I'll see what I can do. I really need to get #30627 done. It's in the last 5% which is the longest part.

I'm just wondering, how the mqtt5 conflicts, but more in general a "sub-package" availability is modelled?

@hainest your input on this question would be valuable! I wasn't quite sure about the various (seemingly) ad-hoc conflicts and methods of enabling/disabling subpackages, so I only included the on that seems to be used the most, namely

        if not spec.satisfies("@1.88.0:"):
            with_libs.discard("mqtt5")

That's good enough for now. I'm drastically changing variant modelling in #30627. I really need to finish that work. It's been lingering for too long.

but I certainly wouldn't mind modeling that as a conflict instead. I just didn't want to start changing that for all the subpackages as that would be a significantly bigger change.

Yes. It's a ridiculously bonkers big change that I've lost many hairs over.

Unrelated, but do the build failures here look familiar to anyone: https://gitlab.spack.io/spack/spack/-/jobs/16344209#L423? A number of packages are failing with

error while loading shared libraries: libunwind.so.8: cannot open shared object file: No such file or directory

which sounds unrelated enough that it could be a failure that's already on develop, but I wouldn't be surprised if the new version of boost somehow triggers an error like that.

That's running on a machine at UOregon. I have access to it, so I'll see if I can reproduce it.

@spackbot re-run failed pipelines

That's good enough for now. I'm drastically changing variant modelling in #30627. I really need to finish that work. It's been lingering for too long.

Ooh, awesome. I wasn't aware of that PR, and it's nice that you're working on it! In that case I'd definitely prefer to stick to the current suboptimal conflicts and let you handle it in #30627 😉

Unrelated, but do the build failures here look familiar to anyone: https://gitlab.spack.io/spack/spack/-/jobs/16344209#L423? A number of packages are failing with

error while loading shared libraries: libunwind.so.8: cannot open shared object file: No such file or directory

which sounds unrelated enough that it could be a failure that's already on develop, but I wouldn't be surprised if the new version of boost somehow triggers an error like that.

That's running on a machine at UOregon. I have access to it, so I'll see if I can reproduce it.

The CI jobs are using a compiler wrapper, so I can't really test this. I'll see if I can get the bot to re-run the jobs.

@spackbot re-run pipeline

I've rebased on latest develop. Apparently some/all the CI failures should be known failures that have been fixed (and the cray pipeline is known to be finicky...).