Users often find themselves wanting to disable USE settings for only a specific set of packages while wanting the same USE settings enabled for other packages. Currently users can do something like the following: export USE="-X" emerge package This will build the package with the X USE setting disabled. Portage records the USE keywords but never uses them again. If the package is part of the system or world profile and is updated via "emerge --update world" these custom USE keyword settings are ignored. I would recommend one of the following be added to portage (I think the second way would probably be the easiest on users): 1. Manual Override Let a user specify a specific set of USE settings upon merging a package like the following: emerge --set-use="-X" package Portage would apply the --set-use USE setting set and always apply it unless specifically told not to during an update world or update system. The following could also be added to allow users to maintain these settings: emerge --list-use package emerge --forget-use package 2. Automatic Override When a package is first merged, the current USE settings are recorded (including environment, etc). Unless specificly told not to, an update world would reuse the recorded USE settings for each package emerge --update world --reset-use Manual merging of a package via "emerge package" would modify the USE settings recorded for that package. So basically: if the user directly merges it, it records and uses the current USE settings... if --update world merges it, it uses the recorded USE settings for that package. "emerge --update world --reset-use --emptytree --pretend" would have the effect of resetting all USE settings to match the ones currently defined...
Oh, and while we are adding such a facility, we should do it in a generic manner so other stored fields (to be defined in the future) could be stored on manual merge and reused by --update world.
*** Bug 10876 has been marked as a duplicate of this bug. ***
It may be more user-friendly if a new file was added, similar to the way /etc/portage/package.mask works. For example, it could be named /etc/portage/package.use and add entries in this format: dev-php/mod_php -java This wouldnt cause unexpected behaviours, since only explicitly written USE flags are sticky.
What we really need is an /etc/make.conf.d/general-specific/packagename system.. make.conf.d/ would contain: useflags file and chost file and cflags file and compileroptions file or maybe just useflags and compileroptions... and a readme file.. this would all generate a make.conf file for backwards compatibility... and would solve some of the evilness of updating files... because we want to keep our systems up to date... but we don't want to accedentally loose our settings. (especially in multiple developer settings) We'd be able to set options for specific packages... and each package could have special use flags.... but would by default resort to the /etc/make.conf ... which would be generated by make.conf.d data
IMO package.use and package.keywords are sufficient *** This bug has been marked as a duplicate of 13616 ***
