Rich Freeman <rich0 <at> gentoo.org> writes:
> > The --autounmask option for emerge, which is on be default, partially > > automates this. --autounmask-write takes it a small step further, but you > > still have to run etc-update to apply the changes. Yes, I have had '--autounmask-write y' as part of my EMERGE_DEFAULT_OPTS= in make.conf for a few years now. it does help. after it does it's thing, I parse out the permanent flag setting to /etc/portage/package.use/package.use. As of today, I now manually parse out the abi_x86_32 flags into /etc/portage/package.use/abi.use, knowing that the system does autoset the 64bit as default for the default amd64 profile. > This is about the only solution today. There has been talk of > implementing "lazy use flags" that would let portage implicitly change > USE settings when the user hasn't explicitly told it not to. (That > is, interpret -flag as the user intends to leave it off, and flag as > the user intends to set it, and if it isn't mentioned one way or the > other let portage just follow profile/package defaults and add > per-package flags when needed to satisfy dependencies.) This was > motivated in part by the package.use explosion caused by 32-bit libs. I must confess to reading that thread, only too quickly. If I recall some folks had an informal mechanism to already implement their idea of 'lazy flags'? I'll have to reread that thread to parse out a few ideas on how to move forward... > However, none of this exists today. As stated above, using /etc/portage/package.use/abi.use as a file to exclusively put all of those settings, I hope a hack of an idea emerges to solve this situation. Maybe an extended attribute that allows one to take specific flages (like abi_x86_32) and put those into an isolated file under /etc/portage/ might be an easy extension until the one of the devs moves forward on this opportunity to implement 'lazy flags'? Thx for the info and suggestions. James