--newuse default action is to emerge apps which USE flags have been changed. However, this will also reemerge packages even if you didn't change their flags. I propose a new option to be used with --newuse: --changeduse. It will emerge the packages with new uses AND with USE flags the system admin modified. Resuming: --newuse: (Re)emerges the packages with USEs marked as % and * --newuse --changeduse: (Re)emerges the packages with USEs marked only as * Another enhancement that could be considered is giving --newuse a new behavior: --newuse: Only emerges packages with * --newuse --anewoption: * and % It all depends if % changes are really required while reemerging a system. IMHO, * is more important.
IUSE records the flags that affect a given package. When the package version remains unchanged, a % symbol reflects a change in IUSE. It's possible that % and * may overlap for a given flag. There a many different types of interactions that can happen it's not possible for portage to determine exactly where % and * overlap and where they do not. Thus, portage does not attempt to make that distinction.
So if % and * and maybe other types interactions may overlap each other, does that mean they are stored in the same variable/place, even if represent different things? Maybe Portage doesn't need to make distinctions because there aren't any to be done. One IUSE can be fresh, and it can be a newly set IUSE, so %* at the same time.
(In reply to comment #2) > So if % and * and maybe other types interactions may overlap each other, does > that mean they are stored in the same variable/place, even if represent > different things? Yes, and sometimes the information isn't even stored at all. For example, USE flag can affect an ebuild even when it's not listed in IUSE (though it's a QA violation, many ebuilds don't properly specify IUSE). > Maybe Portage doesn't need to make distinctions because there aren't any to be > done. One IUSE can be fresh, and it can be a newly set IUSE, so %* at the same > time. I'm not sure what you mean. It's best expressed in terms of IUSE and USE. These values can be examined via the metadata function of portageq. For example: portageq metadata / ebuild sys-apps/portage-2.1-r2 IUSE portageq metadata / installed sys-apps/portage-2.1-r2 IUSE portageq metadata / installed sys-apps/portage-2.1-r2 USE
The important thing to note here is that if a flag is added to or removed from IUSE portage can't know what happened: a) a feature that was hard enabled became optional (so the package changes if the flag is not set in USE) b) a new optional feature was added (so the package changes if the flag is set in USE) c) an optional feature is now hard enabled (see a) d) an optional feature was dropped (see b)
Thanks for the explanation, now I get the whole difference between USE and IUSE. So, in terms of set theory: A is a set of IUSE of a currently installed version of the package. B is a set of IUSE of a the version of the package to be installed. W = B - A X = A - B if W is not empty then it contains the new IUSE. if X is not empty then it contains the dropped IUSE. --newuse takes care of the cases above. ------ C is the USE set of the moment when the current installed package was emerged. D is the USE set now. E = A intersects C (the enabled IUSE back then) F = B intersects D (the enabled IUSE now) Y = F - E Z = E - F if Y is not empty then it contains the now enabled IUSE. if Z is not empty then it contains the now disabled IUSE. So, if an IUSE was added or dropped, but it wasn't enabled in USE, then there won't be changes, and it won't need a recompilation. --changeduse takes care of these. Now I just need to find out if Portage keeps track of enabled IUSE for each installed package. The change from optional to required dependency and vice-versa isn't treated here, these changes should generate a new ebuild version, at least a new release (-r{DIGIT}). Portage will grab them and just update, even if it's not needed. Usually this kind of change is big enough to get its own version, isn't it?
(In reply to comment #5) > Now I just need to find out if Portage keeps track of enabled IUSE for each > installed package. They're stored in /var/db/pkg/*/*/IUSE and retrievable via the portageq command that I mentioned earlier. > The change from optional to required dependency and vice-versa isn't treated > here, these changes should generate a new ebuild version, at least a new > release (-r{DIGIT}). Portage will grab them and just update, even if it's not > needed. Usually this kind of change is big enough to get its own version, isn't > it? Ideally, yes. However, I'm pretty sure that the behavior of gentoo devs often isn't ideal. In addition, a change in an eclass can affect all the ebuilds that inherit it. In that case it may not be feasible to revbump all of the affected ebuilds.
Sure, we can always add yet another command line option, but perhaps things like --newuse and --changeduse really belong in the realm of packages sets (bug 96088).
*** Bug 151337 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Sure, we can always add yet another command line option, but perhaps things > like --newuse and --changeduse really belong in the realm of packages sets (bug > 96088). That would likely need sets that can accept arguments and a more complex return type than just atoms (or can we use use-deps for that?).
(In reply to comment #9) > That would likely need sets that can accept arguments and a more complex return > type than just atoms (or can we use use-deps for that?). Well, --newuse and --changeduse aren't really sets by themselves. They're actually package selection modifiers that are applied to normal sets. The --deep and --emptytree modifiers are other examples of this. These package selection modifiers are hardcoded into the current resolver but eventually they'll be split out into separate modules.
Created attachment 123176 [details, diff] portage-2.1.3_rc5 patch adding support for --reinstall=changed-use This implements a --reinstall=changed-use option which behaves like the --changeduse option described in comment #5.
This has been released in 2.1.3_rc6.
