Thank you, both!

On 15/11/2024 14:05, Jacques Montier wrote:
> What if you try this :
> emerge -auvDN --getbinpkgonly --with-bdeps=y --binpkg-respect-use=y --
> keep-going world

This does indeed suggest to replace existing builds with the upstream binary ones. I traced this to --getbinpkgonly which seems to force the use of the binary packages over source builds where possible.

There are, however, minor differences between this and my earlier example with --rebuilt-binaries. Using "--getbinpkgonly" suggests a few downgrades, including to sys-kernel/gentoo-sources.

"--binpkg-respect-use=y" makes no difference as emerge(1) suggests this is the default.

On 15/11/2024 14:15, Matt Jolly wrote:
You want to match the binhost flags:

https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart#x86-64-v3_variant

That was my assumption as well. But doing so and running a rebuild of @world with --emptytree did not yield any differences in which binar y packages are used between "-march=x86-64-v3" and "-march=znver4".

What caught my attention was a passage from the detailed guide:

"""
* The builder and client architecture and CHOST must match.
* The CFLAGS and CXXFLAGS variables used to build the binary packages must be compatible with all clients.

...

Portage can not validate if these requirements match. In case of doubt, it is the responsibility of the system administrator to guard these settings.
"""

This made me wonder if CFLAGS need to match exactly in a situation, such as mine, where -march=znver4, being newer, is compatible and anything built with has "-march=x86-64-v3" /should/ run fine.

If my understanding is correct, then the local value for CFLAGS should only affect the source builds.

> If you're currently using x86-64-v4 there's no benefit to replacing the
> existing packages. Just let them age out and be replaced over time as
> as new versions are released.

Indeed, that's my
understanding too. Combined with being the same version, I suspect this is why emerge is not suggesting to replace the existing source builds with the binary builds, but is happy to do so with the nuclear "--emptytree" approach.


Best Regards,
Victor

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to