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







Reply via email to