Bugzilla Bug 144333

--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 an attachment (id=123176) [details]
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.