Bugzilla Bug 151337

When there wasn't any change of normal USE flags, but there was some change of
existence of USE_EXPAND flags, emerge shouldn't want to reemerge a package.

I think about 2 cases:
 - At the beginning some USE_EXPAND flag wasn't in IUSE, and next it was added
to IUSE, but user has this flag disabled.
 - At the beginning some USE_EXPAND flag was in USE and user had this flag
disabled, and next this flag was removed from IUSE.


Example:

$ emerge -Npv k3b

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] app-cdr/k3b-0.12.17  USE="alsa arts css dvdr encode ffmpeg flac
hal kde mp3 musepack sndfile vcd vorbis -debug -musicbrainz -xinerama"
LINGUAS="pl -af -bg -bn -br -bs -ca -cs -cy -da -de -el -en_GB -es -et -eu -fi%
-fr -ga -he -hi -hu -is -it -ja -km -lt -mk -ms -nb -nds -nl -nn -pa -pt -pt_BR
-ro -ru -se -sl -sr -sr@Latn -sv -ta -tr -uk -zh_CN -zh_TW%" 3,914 kB

Total size of downloads: 3,914 kB
$ emerge -Np k3b

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] app-cdr/k3b-0.12.17  LINGUAS="-fi% -zh_TW%"
$ cat /var/db/pkg/app-cdr/k3b-0.12.17/IUSE
alsa css dvdr encode ffmpeg flac hal kde mp3 musepack musicbrainz sndfile vcd
vorbis linguas_af linguas_bg linguas_bn linguas_br linguas_bs linguas_ca
linguas_cs linguas_cy linguas_da linguas_de linguas_el linguas_en_GB linguas_es
linguas_et linguas_eu linguas_fr linguas_ga linguas_he linguas_hi linguas_hu
linguas_is linguas_it linguas_ja linguas_km linguas_lt linguas_mk linguas_ms
linguas_nb linguas_nds linguas_nl linguas_nn linguas_pa linguas_pl linguas_pt
linguas_pt_BR linguas_ro linguas_ru linguas_se linguas_sl linguas_sr
linguas_sr@Latn linguas_sv linguas_ta linguas_tr linguas_uk linguas_zh_CN debug
xinerama arts

Finnish and traditional Chinese languages support was added, but I think that
reemerging K3b because of this is pointless.

Improved --newuse behaviour should concern all types of USE_EXPAND flags
(LINGUAS, VIDEO_CARDS, INPUT_DEVICES, ...)

I think that current (rather pointless) behaviour could remain as "--newuse
--newuse" / "-NN".

-1

* neverending changes in behaviour are annoying and confusing
* adding of supported languages/drivers/etc is extremely useful for some users
and they should know about it
* having a different behaviour for USE_EXPAND than for normal USE flags is
inconsistent
* noone's forcing you to re-emerge if the changes are not relevant for you

(In reply to comment #0)
> I think that current (rather pointless) behaviour could remain as "--newuse
> --newuse" / "-NN".
I recall this. Current behaviour shouldn't remain.

Gotta disagree here. New behaviour makes sense, even if it takes some getting
used to.

(In reply to comment #1)
> -1
> 
> * neverending changes in behaviour are annoying and confusing
> * adding of supported languages/drivers/etc is extremely useful for some users
> and they should know about it


This improvement wouldn't be noticed by users.

(In reply to comment #4)
> (In reply to comment #1)
> > -1
> > 
> > * neverending changes in behaviour are annoying and confusing
> > * adding of supported languages/drivers/etc is extremely useful for some users
> > and they should know about it
> 
> 
> This improvement wouldn't be noticed by users.

It would sooner or later.
> 

I second this request.

Since the new behaviour of portage 2.1.1 I cannot update with a normal emerge
-auvDN world anymore after I changed my USE in the make.conf. Currently it
wants to pull openoffice and many other packages again because of changed
languages or useflags in the IUSE I would never use.

Actually I miss the old way, emerging with -N and if some of my useflags are
new I got them. Now I have to pretend and have to see what new useflags maybe
important for me, like "cracklib" in the last shadow-ebuild.

Ebuilds like OpenOffice are now really update-blockers. The last last release
has new LANGUAGES and a IUSE like mono. Portage would like to remerge
OpenOffice because of the new languages I do not have in my make.conf oder 
the new useflag mono that would be remerge with -mono, so no benefit for me.

Here a list of my current emerge -auvDN world, all with really useless
remerges:

These are the packages that would be merged, in order:

Calculating world dependencies... done!
[ebuild   R   ] sys-libs/glibc-2.4-r3  USE="nls nptl nptlonly -build
-glibc-compat20% -glibc-omitfp -hardened (-multilib) -profile (-selinux)" 0 kB
[ebuild   R   ] dev-lang/ruby-1.8.5  USE="-cjk -debug -doc -examples -ipv6
-socks5 -threads -tk% (-tcltk%*)" 0 kB
[ebuild   R   ] net-misc/neon-0.26.1-r1  USE="nls ssl zlib -expat -socks5
(-static%)" 0 kB
[ebuild   R   ] app-office/openoffice-2.0.3  USE="cairo eds firefox gtk java
kde pam xml -binfilter -debug -gnome -ldap -odk (-mono%)" LINGUAS="de -af -ar
-be_BY -bg -bn -bs -ca -cs -cy -da -el -en -en_GB -en_US -en_ZA -es -et -fa -fi
-fr -gu_IN -he -hi_IN -hr -hu -it -ja -km -ko -lt -mk -nb -nl -nn -nr -ns
-pa_IN -pl -pt -pt_BR -ru -rw -sh_YU -sk -sl -sr_CS -st -sv -sw_TZ -th -tn -tr
-ts -vi -xh -zh_CN -zh_TW -zu" 203,676 kB
[ebuild   R   ] app-cdr/k3b-0.12.17  USE="alsa arts css dvdr encode ffmpeg hal
kde mp3 musicbrainz vcd vorbis xinerama -debug -flac -musepack -sndfile"
LINGUAS="de -af -bg -bn -br -bs -ca -cs -cy -da -el -en_GB -es -et -eu -fi% -fr
-ga -he -hi -hu -is -it -ja -km -lt -mk -ms -nb -nds -nl -nn -pa -pl -pt -pt_BR
-ro -ru -se -sl -sr -sr@Latn -sv -ta -tr -uk -zh_CN -zh_TW%" 9,495 kB
[ebuild   R   ] app-text/acroread-7.0.8  USE="cups nls nsplugin -ldap"
LINGUAS="de -da% -es% -fi% -fr -it% -ja -ko -nl% -no% -pt% -sv% -zh_CN -zh_TW"
48,214 kB
[ebuild   R   ] x11-themes/thinkeramik-3.2.1  USE="xinerama -debug (-arts%*)"
715 kB

Total size of downloads: 266,407 kb      


Please change this back to the old behaviour.

Cheers

Rafael

This bug seems like it might be a duplicate of bug 144333.  We're not adding
any special cases for USE_EXPAND flags.  When we get support for dynamic
package sets,  something like that might be able to be implemented as a custom
component.

(In reply to comment #6)
> Please change this back to the old behaviour.

Something similar to the old behavior should eventually be available (see bug
144333).  If the portage tree remains constant (no --sync in between), the
current --newuse behavior is actually the same as the old behavior.  It's only
when the live ebuilds in the portage tree have diverged from the installed ones
that the behavior is different.

(In reply to comment #0)
> When there wasn't any change of normal USE flags, but there was some change of
> existence of USE_EXPAND flags, emerge shouldn't want to reemerge a package.

I can see how it might be useful to categorize the flags somehow, to separate
flag changes for which it is more important to recompile the package. 
USE_EXPAND groups do not serve to categorize flags that way, however.  If you
want to introduce a new method to categorize flags, then the best way to
propose that would probably be a GLEP.

*** This bug has been marked as a duplicate of bug 144333 ***