media-gfx-openvdb inconsistent rebuild request... silly?

[CaptainBlood]

Code: Select all

emerge -p -uDUv world --exclude zig

These are the packages that would be merged, in reverse order:

Calculating dependencies  ..............
... done!
Dependency resolution took 274.19 s (backtrack: 0/20).

!!! The ebuild selected to satisfy "media-gfx/openvdb:0/11.0=" has unmet requirements.
- media-gfx/openvdb-11.0.0-r1::gentoo USE="-abi10-compat abi11-compat -abi12-compat -abi9-compat -alembic ax blosc (-cuda) -doc -examples -jpeg -nanovdb -numpy -openexr -png -python -static-libs -test -utils zlib" ABI_X86="(64)" CPU_FLAGS_X86="avx sse4_2" LLVM_SLOT="(-15)" PYTHON_SINGLE_TARGET="-python3_11 -python3_12"

  The following REQUIRED_USE flag constraints are unsatisfied:
    ax? ( llvm_slot_15 )

  The above constraints are a subset of the following complete expression:
    at-most-one-of ( abi12-compat abi11-compat abi10-compat abi9-compat ) ax? ( exactly-one-of ( llvm_slot_15 ) ) cpu_flags_x86_avx? ( cpu_flags_x86_sse4_2 ) python? ( exactly-one-of ( python_single_target_python3_11 python_single_target_python3_12 ) ) blosc? ( zlib )

!!! /etc/portage/package.env references non-existent file: /etc/portage/env/cc-lto-ebuild-filter-no-hardened-error
(dependency required by "sci-libs/vtk-9.4.2-r2::gentoo" [installed])
(dependency required by "media-gfx/freecad-1.0.2-r2::gentoo" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

Code: Select all

=================================================================
                        Package Settings
=================================================================

media-gfx/openvdb-11.0.0-r1::gentoo was built with the following:
USE="-abi10-compat abi11-compat -abi12-compat -abi9-compat -alembic ax blosc (-cuda) -doc -examples -jpeg -nanovdb -numpy -openexr -png -python -static-libs -test -utils zlib" ABI_X86="(64)" CPU_FLAGS_X86="avx sse4_2" LLVM_SLOT="(15)" PYTHON_SINGLE_TARGET="-python3_11 -python3_12"
CFLAGS="-march=core2 -mtune=native -Werror=lto-type-mismatch -Werror=odr -Werror=strict-aliasing -O2 -pipe -Wa,-mbranches-within-32B-boundaries -fno-strict-aliasing"
CXXFLAGS="-march=core2 -mtune=native -Werror=lto-type-mismatch -Werror=odr -Werror=strict-aliasing -O2 -pipe -Wa,-mbranches-within-32B-boundaries -fno-strict-aliasing"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live compress-build-logs config-protect-if-modified distlocks ebuild-locks export-pms-vars fixlafiles ipc-sandbox merge-sync merge-wait multilib-strict network-sandbox news parallel-fetch pid-sandbox pkgdir-index-trusted preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms split-elog strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"

Is it side effect of bugzilla & repos/gentoo.git?

Thks 4 ur attention, interest & support.

[asturm]

wHAT?

[Hu]

CaptainBlood: why do you still have openvdb-11? As I read history, openvdb-12 has been stable on amd64 since May 2025.

[CaptainBlood]

Got it...
For whatever forgotten reason 12.0.1::gentoo has been masked here.
However 11.0.0-r1::gentoo is here still and as stable as 12.0.1 too.

Seems like this 2 days old commit has brought inconsistency to stable ::gentoo here.

Code: Select all

(2026-01-13)
+# LLVM 15 is only required by masked packages.  It will be removed when
+# the reverse dependencies are gone.  Bug #920536.
+llvm_slot_15

Would appropriate tooling in the sys-apps/portage stack have been able to prevent the raise of such a decoherence? Let's think it over...

Thks 4 ur attention, interest & support.

[sam_]

Where is the stable tree broken or incoherent?

The USE flag is masked and you've unmasked it:
base/package.use.mask:137:media-gfx/openvdb ax

That means nothing is guaranteed.

[asturm]

For whatever forgotten reason 12.0.1::gentoo has been masked here.

Someone else would have used that as an opportunity for some self-reflection ...

[sam_]

[CaptainBlood]

Where is the stable tree broken or incoherent?

The USE flag is masked and you've unmasked it:
base/package.use.mask:137:media-gfx/openvdb ax

That means nothing is guaranteed:

That's indeed a SERIOUS comment,

Code: Select all

grep -r media-gfx/openvdb /etc/portage/*|grep ax
/etc/portage/package.use/media-gfx::openvdb.conf:media-gfx/openvdb ax
/etc/portage/profile/package.use.mask/media-gfx::openvdb.conf:=media-gfx/openvdb-11.0.0-r1 -ax
/etc/portage/profile/package.use.mask/media-gfx::openvdb.conf:=media-gfx/openvdb-12.0.1 -ax

Thks 4 ur attention, interest & support.

[Hu]

CaptainBlood: what are you trying to say here? As I read the thread, you sabotaged yourself twice over:

• You masked an upgrade that you should have taken, which would have kept you out of trouble.
• You unmasked a flag that the Gentoo developers masked because they knew that leaving it unmasked would cause trouble. Once unmasked, you then enabled it, and got into trouble.

The Gentoo project makes reasonable efforts to avoid dependency errors, but has never promised that you can arbitrarily enable and disable masks, and expect a consistent result. Masks are a major way that the developers keep naive users away from known issues. If you override the mask, you take responsibility for any otherwise unreachable issues that you can now reach.

[sam_]

In addition to that, the reasons for masks are not always instability (or just instability) but because say, a feature relies on a dependency that must be removed, and we either want to give a grace period for users to override that (as opposed to dropping the USE flag immediately and then last-riting, it's like "last-rites" for a USE flag), or we want to be able to restore the functionality if the software can use a newer or different dependency in future.

Overriding that to unmask it without appreciating that will inevitably lead to something like this where it gets removed for real and one is then surprised.