dropping ABI_X86="32" partially

[krinn]

i'm bored by ABI_X86="64 32" and while i wish keep "some" 32, i don't want my system to keep building things in 32bits that i will just never use.

the problem is the masking:
* i can mask abi_x86_32 and unmask it per package (that's dangerous if i forget something important, but the easiest to do as i suppose the package list will be shorter)
* or leave abi_x86_32 and mask it per package (that's the top boring as the list of package will be huge and need update on any new package)

Anyone has done it? If so can you provide solution you have taken and the mask/unmask file.

edit: so i decide to take the masking per package safer path.
here's my way to get list of package to review : equery h abi_x86_32 | cut -d"]" -f2 | sed 's/-[0-9].*/ -abi_x86_32/' > /etc/portage/package.use/disable_abi_32

[ali3nx]

When the ABI flag was introduced i quickly discovered that using ABI_X86="64 32" on systems that required 32 bit libraries was far less effort than per package unmasking.

With that mentioned I have had to mask abi_x86_32 per package on a few rare occasions. It is entirely possible but doing this on many packages is i believe just as much effort as unmasking each package requiring abi_x86_32.

dev-lang/mono some months ago for example as a dependency for ~arch versions of wine-staging wouldn't build with abi_x86_32 so disabling it in package.use immediately fixed the issue at the time.

[fedeliallalinea]

I'm in a multilib profile and I never masked abi_x86_32 and system manage that very well. I don't have ABI_x86="64 32" variable in make.conf and the only packages compiled in 32bit is for nvidia-drivers and bublebee:

[krinn]

i did switch to amd64 not so far again only, so i have just use a multilib profile and let it go.
but it's boring to see 32bits version of some packages (seriously, who need 32 and 64bits version of sys-apps/file???)
i'm quickpkg my stuff before going into havoc, while waiting comments from someone that has taken the ABI="64" path.

[krinn]

fedeliallalinea:
How you did, here's my result

[Jaglover]

You sure you still need 32 bit? I switched all my boxes over to no-multilib a year or more ago and never looked back.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[Cuong Nguyen]

Calculate Linux - a Gentoo derivative binary distro - uses ABI_X86="64" and put per package USE-flags abi_x86_32 in default profile package.use https://paste.pound-python.org/show/YFAHPGqLjew4ERSGXxmT/

[fedeliallalinea]

I enable abi_x86_32 only when a package need it, I never added 32 in ABI_X86 varibale in make.conf
_________________
Questions are guaranteed in life; Answers aren't.

[krinn]

[krinn]

[Ant P.]

I've got a long list of 32-bit cruft installed (steam is the worst software I've used in 20 years...) but I enable it only when portage complains:

[Jaglover]

32-bit with multilib is like spiderweb, the packages depend on each other 32 bit support. It takes time to break out partially as krinn wishes.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[ali3nx]

The per package unmasking is a wonderful thing but then you have to maintain all of those extra use flags.

I replied to someone on these forums last year that didn't know you could global unmask ABI_X86="64 32" in make.conf and that person's package.* files were one of the greatest examples of gentoo user tenacity i've witnessed in over ten years
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper!

[krinn]

i have taken fedeliallalinea's path, ABI="64" set and i will reenable abi_x86_32 per package ; and oh well, let's see what happen
i'll tell you about the result later, right now i have 276 packages to rebuild

[Jaglover]

It is like this: package A has abi_x86_32 because package B has it. And package B has it because package C has it. And the only reason package C has it is because package A has it. You go ahead and try to break this mess.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[Ant P.]

I wish autounmask wasn't such a dumb implementation for that reason. If I want to install things like wine and steam-runtime that have about a hundred ABI_X86 things to tweak, it could recognise all of them are coming from one package and name the package.use/$file after that. And then add the file to the package's contents, so uninstalling it removes those deps. Or better yet, why should we have to specify the obvious at all? If I have app-emulation/wine ABI_X86: 64 32 there should be a make.conf setting to tell portage to figure out the rest and not bother me.

I'd say something similar ought to be done for all the dumb packages that USE_DEPEND on PYTHON_TARGETS=python2_7 but don't p.use.mask it that way - but tautologies like that should just be a repoman violation.

[Cuong Nguyen]

[krinn]

[Cuong Nguyen]

[krinn]

Here's my results:

[Anon-E-moose]

I have about 60 some odd packages with abi_x86_32 in my package.use file (out of some 850~ packages) because I was running wine at one point.
I have a newer laptop that I started as 64 only and it works just fine.

[krinn]

yes, wine will make the list grow again for sure.

[Anon-E-moose]

Out of those 152, I would imagine fully half won't really need the abi 32 flag.

I chose the long way and just edited the package use file every time I got a block when installing wine.

And of course X needs some 32 bit flags, just because you might want to run 32 bit binaries.


I'm seriously considering just changing my multi-lib to 64 bit only since I quit running wine (in favor of qemu and some version of windows instead)
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[krinn]

here it is for curiosity
https://paste.pound-python.org/show/J62xOEzMzf3wV0GhL1SE/

going from ~250, downto 1, then raise back to ~150 just for wine
doesn't look worth the effort