Re: [gentoo-user] Migrating existing Gentoo to binpkg

[byte.size226@simplelogin.com]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]