Portage does not reemerge packages for which new flags have been added when doing a `emerge -NDptv world`
From the output you can see that it identified the new flags and displays them correctly for the packages that had updated dependencies. So samba should be reemerged because of the examples use flag and doxygen because of the unicode flag.
[nomerge ] net-fs/samba-3.0.20b USE="acl -async -automount cups doc examples* kerberos ldap -ldapsam libclamav -mysql -oav pam -postgres python -quotas readline -swat syslog -winbind -xml xml2"
[nomerge ] dev-libs/popt-1.7-r1 USE="nls"
[nomerge ] media-libs/libcaca-0.9-r1 USE="X doc -imlib ncurses -slang"
[nomerge ] app-doc/doxygen-1.4.5 USE="doc qt -tetex unicode*"
[nomerge ] app-text/ghostscript-7.07.1-r10 USE="X -cjk cups -emacs -gtk"
[ebuild U ] net-print/cups-1.1.23-r7 [1.1.23-r6] USE="-cjk gnutls nls pam samba -slp ssl" 0 kB
[ebuild U ] app-text/poppler-0.4.3-r1 [0.4.3] USE="-cairo -gtk jpeg qt zlib" 0 kB
Portage 2.1_pre2 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r3, 2.6.14-gentoo-r5 x86_64)
System uname: 2.6.14-gentoo-r5 x86_64 AMD Athlon(tm) 64 Processor 2800+
Gentoo Base System version 1.12.0_pre12
ccache version 2.4 [enabled]
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
CFLAGS="-march=athlon64 -O3 -pipe -fomit-frame-pointer -fforce-addr -ftracer -fgcse-sm -fgcse-las -fgcse-after-reload"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon64 -O3 -pipe -fomit-frame-pointer -fforce-addr -ftracer -fgcse-sm -fgcse-las -fgcse-after-reload -fuse-cxa-atexit"
FEATURES="autoconfig ccache collision-protect distlocks sandbox sfperms strict"
GENTOO_MIRRORS="ftp://ftp.roedu.net/pub/mirrors/gentoo.org ftp://ftp.lug.ro/gentoo ftp://gentoo.romnet.org http://distfiles.gentoo.org"
Unset: ASFLAGS, CTARGET
*** Bug 116961 has been marked as a duplicate of this bug. ***
--newuse requires --update.
Actualy no, according to portage:
>>> --newuse implies --update... adding --update to options.
I just don't bother adding u to the list of options most of the time. Anyway, bofore reporting this I also tried with emerge -NuDptv world and I got the same result.
*** Bug 117167 has been marked as a duplicate of this bug. ***
Aha, so --newuse is working just as well as it was before. The issue is that USE flags that have been added to a package are now displayed separately. So how to fix this? If a USE flag has been added and is enabled, should the package be recompiled? What about if it has been added but is disabled?
(In reply to comment #5)
> If a USE flag has been added and is enabled, should the
> package be recompiled? What about if it has been added but is disabled?
It's somewhat redundant in the second case, isn't it? How will an added but disabled use flag change the outcome?
Cases where functionality that wasn't optional but always built has become optional and the user would seem to prefer that it isn't built.
(In reply to comment #7)
> Cases where functionality that wasn't optional but always built has become
> optional and the user would seem to prefer that it isn't built.
To me "newuse" means if the use flags changed in any way shape or form the package should be up for recompilation. Thats the behavior I expect out of it anyway. If there is a new functionality that used to be default but now is off ...that shouldn't cause problems with depclean because a new use flag = revbump and the user would already have it installed, so I see no reason not to stick with that kind of behavior.
*** Bug 129398 has been marked as a duplicate of this bug. ***
That last point that Alec made is kind of interesting. The symptoms of this "bug" can only happen if USE flags hae changed for a package but no rev bump has been made. Perhaps *any* change in [I]USE should trigger --newuse so that, at minimum, devs can be yelled at? ;)
Would someone with sufficient privilege please change the summary of
this bug. Missing details from the summary of this bug were why I
missed it when searching for a prior bug report (I searched for
"emerge" and "newuse") and instead filed a new one. Here is the new
summary I suggest (mostly copied from bug 129398 which is marked
duplicate of this bug):
"emerge --deep --newuse world" does not notice ebuilds changed to refer to additional USE flags (sys-apps/portage-2.1_pre*)
This bug is about ebuilds that have been modified to refer to
additional USE flags since last being emerged. "emerge --newuse" does
not notice such ebuilds.
I argue that "emerge --newuse" should notice such ebuilds. Suppose
ebuild cat/package-1.2.3 has added USE flag "xyzzy". Maybe the
current state (enabled or disabled) of "xyzzy" will imply that
re-emerging cat/package-1.2.3 will make a difference. If so, it
should be re-emerged right away if I now do "emerge --newuse --deep
world". But even if the ebuild's behavior has not changed with the
current status of "xyzzy", if I now toggle the status of "xyzzy" and
do "emerge --newuse --deep world", cat/package-1.2.3 should be
re-emerged. Because emerge has no way of knowing for sure it should
be conservative and re-emerge the package.
This is fixed in svn r4014 and r4015.
This has been released in 2.1.1_pre3-r5.
This is a pretty big change in functionality, since my system wants to now recompile over 50 packages that portage-2.1.1_pre3-r4 did not.
I don't disagree with any of the reasoning, but we should probably publicize the change prior to this going stable.
(In reply to comment #14)
> This is a pretty big change in functionality, since my system wants to now
> recompile over 50 packages that portage-2.1.1_pre3-r4 did not.
> I don't disagree with any of the reasoning, but we should probably publicize
> the change prior to this going stable.
First of all, thanks for fixing this bug :)
I agree it should be publicized. It can further become confusing for the user, if a USE flag was removed, then the verbose+pretend/ask output won't list the removed flag, and it all looks like unnecessary rebuild, and you can't see why. This could trigger many bug reports from non-informed users... It would be best to display the removed flag too, somehow, if it's not too big of a hack :)
It's funny to see all those perl modules remerging because "new" perl use flag, but if it's just once, nevermind :)
*** Bug 141776 has been marked as a duplicate of this bug. ***
remerging when IUSE changed is useless sometimes
1) in cases when it is added and disabled
2) in cases when it is removed and was disabled
3) in some cases when it is added and enabled
examples from my box (only relevant use flags):
[ebuild R ] x11-base/xorg-server-1.1.1 VIDEO_CARDS="-fglrx%"
[ebuild R ] net-analyzer/wireshark-0.99.2 USE="(-selinux%)"
[ebuild R ] app-shells/bash-3.1_p17 (removed -build)
[ebuild R ] dev-libs/expat-2.0.0 (removed -test)
[ebuild R ] app-accessibility/mbrola-3.0.1h-r4 LINGUAS="de%"
in this cases you must look at the ebuilds. the author makes use of linguas_* before... just added it to IUSE
From my point of view I agree with comment #8:
Important changes in IUSE should reach the user via rev-bump (--update only) and not via --newuse. Perhaps this is a nice feature to check if some devs should rev-bump?
In reply to comment #18
1) Well, what if the feature used to be mandatory but is now optional?
That means that you used to be forced to compile that feature, but witch the new ebuild, it can be left out.
2) What about something that used to be optional is now made mandatory? You used to be able to leave out the feature, but you now have to include it.
If developers revbumb only for USE flags changes, then people will probably start complaining about that too.
(In reply to comment #19)
> 1) Well, what if the feature used to be mandatory but is now optional?
> That means that you used to be forced to compile that feature, but witch the
> new ebuild, it can be left out.
I'm not forced, because I'm doing an update. This means I allready have compiled it. It's nice for first install. Now I'm forced to remerge it. I'll get the left out feature sooner or later with a rev-bump.
> 2) What about something that used to be optional is now made mandatory? You
> used to be able to leave out the feature, but you now have to include it.
if the new feature is important it should be rev-bumped or turnd on via profile.
Nevertheless it's nice to have something that cares about switching features mandatory/optional. But it must have a measurable effect. My examples in comment #18 are just a view one with effect=0. I think moast cases will have zero effect. Isn't it? Furthermore I thinks that's why dev's don't rev-bump, because it has no effect or is not urgent.
--newuse is now working on 3 places at the same time:
1) my personal USE flags (make.conf, /etc/portage)
2) profile defaults
3) and now on IUSE from ebuilds in /usr/portage
I'd like to have more granularity, or gentoo'ish more "all about choices".
If you'd like more granularity, see bug 144333. I'm thinking about moving this in to the package set domain and offering more choices there.
Hmm, I experience a really strange thing with the new portage-2.1.1
$ emerge -uDNpvt world
[ebuild R ] net-fs/shfs-0.35-r3 USE="X -amd -doc" 0 kB
[ebuild R ] net-dialup/slmodem-2.9.11_pre20051101 USE="alsa -usb" 0 kB
But why are those two packages on my list???
There are none of this changes indicated: () * %
I really don't understand.
Is this behaviour intended? And why (just curious)?
Thank you for explaining me
See diff below for details
$ diff -u /var/db/pkg/net-fs/shfs-0.35-r3/shfs-0.35-r3.ebuild /usr/portage/net-fs/shfs/shfs-0.35-r3.ebuild
--- /var/db/pkg/net-fs/shfs-0.35-r3/shfs-0.35-r3.ebuild 2006-06-06 01:39:51.000000000 +0200
+++ /usr/portage/net-fs/shfs/shfs-0.35-r3.ebuild 2006-07-12 22:36:30.000000000 +0200
@@ -1,6 +1,6 @@
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/net-fs/shfs/shfs-0.35-r3.ebuild,v 1.3 2006/05/25 14:17:10 hansmi Exp $
+# $Header: /var/cvsroot/gentoo-x86/net-fs/shfs/shfs-0.35-r3.ebuild,v 1.5 2006/07/12 20:12:17 agriffis Exp $
inherit linux-mod eutils
@@ -10,7 +10,7 @@
-KEYWORDS="~alpha ~amd64 ~ia64 ppc ~sparc x86"
+KEYWORDS="~alpha amd64 ia64 ppc ~sparc x86"
IUSE="X amd doc"
(In reply to comment #22)
> Hmm, I experience a really strange thing with the new portage-2.1.1
> $ emerge -uDNpvt world
> [ebuild R ] net-fs/shfs-0.35-r3 USE="X -amd -doc" 0 kB
> [ebuild R ] net-dialup/slmodem-2.9.11_pre20051101 USE="alsa -usb" 0 kB
> But why are those two packages on my list???
> There are none of this changes indicated: () * %
> I really don't understand.
> Is this behaviour intended? And why (just curious)?
No, that behavior looks wrong (there should be at least one of * or %). Can you file a new bug and attach --debug output for the command that behaves unexpectedly?
Reported there ... Bug 147236