Permanent slot conflicts and removing insecure packages

[dinominant]

Years ago I would have a global USE variable in my make.conf so I could enable features that I would like to have. However this often resulted in circular dependencies, failling updates, and a broken system. I started applying USE flags to only the packages that I wanted in /etc/portage/package.use/package-name. In my make.conf I enabled several autounmask options so that dependency packages could have required USE flags enabled and stored in /etc/portage/package.use/zzzz-autounmask-write

The problem is that autounmask always uses ">=" and over time more use flags are enabled, for all future versions, and eventually too many use flags are enabled. They are never restricted to only what is actually needed and a dependency conflict arises. Updates start being skipped, and eventually the system becomes unmaintainable or insecure due to legacy packages never being updated or removed.

I tried emptying my zzzz-autounmask-write however portage never recalculates the dependency use flags if a package is already installed, so I can't really clean up the mess.

I could write a simple script to replace all the '>=' with '=' in zzzz-autounmask-write however this isn't really a proper solution because portage never recalculates what is minimally needed and updates zzzz-autounmask-write based on what I have in /var/lib/portage/world with my current use flags.

emerge has --autounmask-unrestricted-atoms=n however that only applies to keyword and mask changes.

Is there a solution where I can keep using autounmask to resolve dependencies, in a way that does not progressively grow the dependency graph until it is unsolvable over time?

make.conf

[ulenrich]

I never understood this _autounmask_ feature. If I wanted to lose control over my system subsequently, I would have changed to Arch Linux distribution in the first place.

As there are shortcomings with portage dependency resolution every now and then I try my portage system configuration with a pretend:
emerge -1p @installed
And I'll get a full resolution when having in /etc/portage/package.mask:

[Hu]

Autounmask should be viewed purely as a labor-saving alternative to writing the entry to the file by hand. If you need to perform an unmask, letting autounmask write it for you is fine. The problem is if you let it write an unmask entry that you shouldn't write at all, such as unmasking a hard masked package without a clear reason why you need to unmask that package instead of some other solution. Only unmask / change keywords / change USE flags when you can explain why that is the right solution. Never make a change solely because Portage suggests it; it suggests the most expedient path to whatever it thinks you want, which may not always be what you actually want.

[dinominant]

[dinominant]