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

[Eli Schwartz <eschwartz@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4333 bytes --]

On 11/15/24 7:42 AM, byte.size226@simplelogin.com wrote:
> My only question that remains is whether I should change the existing
> value for CFLAGS (I presume so). Currently, I have:
> 
>     COMMON_FLAGS="-march=znver4 -O2 -pipe"
> 
> (yes CFLAGS etc are set to use $COMMON_FLAGS).
> 
> Since I'm planning to use binary packages from x86-64-v3, I presume this
> should be changed to:
> 
>     COMMON_FLAGS="-march=x86-64-v3 -O2 -pipe"
> 
> or, perhaps:
> 
>     COMMON_FLAGS="-march=x86-64-v3 -mtune=znver4 -O2 -pipe" ?


Your CFLAGS are irrelevant here. CFLAGS on the binhost server must be
compatible with your local machine, or you will successfully install
packages that then abort with SIGILL when you try to run the programs.

The reverse is not true -- CFLAGS on your local machine just need to be
compatible with, well, your local machine (where they get installed),
not the binhost, where they don't get installed. :)

It's fully possible to change your CFLAGS in make.conf whenever you
want, run emerge to do world updates etc, and portage doesn't care and
effectively doesn't know you changed it since all installed packages are
"compatible" with that make.conf -- this is extremely unlike USE flags,
which are actually treated as match specifiers and if you change USE,
then emerge insists on rebuilding / reinstalling. Which brings us to...


> I also have a hefty $CPU_FLA
> GS_X86 (also added to $USE) from "cpuid2cpuflags" but am not worried
> about this as packages that don't fit will simply be built from source
> as usual.


Yup. CPU_FLAGS_X86 don't need to be added to $USE because they already
*are* USE. And USE flags will force rebuilds where necessary, or prevent
seeing binary packages as compatible. The binhost already builds with
those USE flags as appropriate for v3 systems, but you may have a couple
more enabled so packages which specifically can take advantage of that,
will be built locally.


> Anyway, in both cases running my usual:
> 
>     emerge -aqvND --update --keep-going --with-bdeps=y @world
> 
> doesn't yield any changes to the system. I presume because, as of now,
> everything is up to date.
> 
> In contrast, adding "--rebuilt-binaries" shows a lot of binary packages
> being pulled in and "--emptytree", as expected, shows a full rebuild
> with a lot of binary packages being pulled in.
> 
> So, to the actual questions:
> 
> 1) What would be the preferred CFLAGS configuration or, since "-
> march=znver4" is a newer subset of x86-64-v3, can I simply keep the
> existing one?


Keep your existing CFLAGS that you were using before enabling the
binhost. It's a free optimization for any packages that you ended up
building from source anyway.


> 2) To reinstall the current source based packages with their binary
> equivalent, "--rebuilt-binaries" sufficient or should I just go for "--
> emptytree @world"?


--rebuilt-binaries will update all packages with their binary
equivalents, if the binary on the server has a BUILD_TIME newer than the
time you rebuilt it locally. This isn't really the same as reinstalling
all source based packages with their binary equivalent.

--emptytree will update all packages with their binary equivalents, and
also update all other packages by building them from source, which isn't
actually what you asked for, though it does what you asked for as a side
effect. Some people encourage running weekly --emptytree anyways,
though. Usually the idea is doing it as an experiment to see whether all
packages still build and run successfully, and report bugs / commit
fixes to gentoo.git whenever issues are encountered. It may also go well
with running ACCEPT_KEYWORDS="**" for sys-devel/gcc and reporting
regressions to the GCC bugtracker. ;)


It's not actually strictly necessary to reinstall all source based
packages with their binary equivalent. If you want to do that though,
you can do that by looping over directories in /var/db/pkg/*/* and
checking which ones have a file called BINPKGMD5 in them. Those were
installed from a binpackage. Try installing all the rest with --ask,
check if it says [binary] or [ebuild], and repeat after manually
narrowing the list to just the ones that offer binaries.



-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]