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 ***
