User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1) Gecko/20061209 Firefox/2.0 Build Identifier: When using emerge with the --tree AND --ask arguments, the tree view shows up correctly (in reverse order) but, upon answering in the affirmative to the --ask option, emerges then in the order shown in the console. If I don't use the --tree option, then the order prints out correctly and compiles in the proper order. If I don't use --ask, it still compiles in the incorrect order. Reproducible: Always Steps to Reproduce: For example: # emerge world --deep --update --ask --tree These are the packages that would be emerged, in revere order: Calculating world dependencies... done! [ebuild U] application_a-1.0-r1 [1.0] [nomerge ] application_b-1.0 [nomerge ] dependency_a-1.0 [ebuild U] dependency_b-1.0-r2 [1.0] Total: 2 packages (2 upgrades) Would you like to merge these packages? [Yes/No]yes Actual Results: >>> Emerging (1 of 2) application_a-1.0-r1 ... etc. Expected Results: >>> Emerging (1 of 2) dependency_b-1.0-r2 ... etc. Unfortunately, I don't have any non-amd64 computers to test this on, but the same bug appears on two x86_64 machines running portage-2.1.2_rc3. The issue I was coming across was set to emerge after the dependent application, and thus the latter refused to compile or the process would just stop.
Sorry, I can't reproduce that. It shouldn't matter what architecture or OS you are using. Here's an example I've just tested with portage-2.1.2_rc3-r4: $ emerge -av mythtv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-libs/libdvb-0.5.5.1-r3 USE="-doc" 0 kB [ebuild N ] media-tv/mythtv-0.20_p11626 USE="alsa dts dvb dvd ieee1394 joystick mmx opengl perl vorbis (-altivec) -backendonly -crciprec -dbox2 -debug -freebox -frontendonly -hdhomerun -ivtv -jack -lcd -lirc -xvmc" VIDEO_CARDS="i810 via -nvidia" 12,108 kB [ebuild N ] x11-themes/mythtv-themes-0.20 13,852 kB Total: 3 packages (3 new), Size of downloads: 25,960 kB Would you like to merge these packages? [Yes/No] n $ emerge -at mythtv These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild N ] x11-themes/mythtv-themes-0.20 [ebuild N ] media-tv/mythtv-0.20_p11626 USE="alsa dts dvb dvd ieee1394 joystick mmx opengl perl vorbis (-altivec) -backendonly -crciprec -dbox2 -debug -freebox -frontendonly -hdhomerun -ivtv -jack -lcd -lirc -xvmc" VIDEO_CARDS="i810 via -nvidia" [ebuild N ] media-libs/libdvb-0.5.5.1-r3 USE="-doc" Would you like to merge these packages? [Yes/No] y >>> Emerging (1 of 3) media-libs/libdvb-0.5.5.1-r3 to /
(In reply to comment #0) > Calculating world dependencies... done! > [ebuild U] application_a-1.0-r1 [1.0] > [nomerge ] application_b-1.0 > [nomerge ] dependency_a-1.0 > [ebuild U] dependency_b-1.0-r2 [1.0] > > Total: 2 packages (2 upgrades) > > Would you like to merge these packages? [Yes/No]yes > Actual Results: > >>> Emerging (1 of 2) application_a-1.0-r1 > ... etc. > > Expected Results: > >>> Emerging (1 of 2) dependency_b-1.0-r2 You failed to tell us but I assume you're using portage-2.1.2. That no longer merges in reverse order unless there's a reason to do so. If application_b needed upgrade it would be merged after dependency_b and after application_a. Since application_a doesn't depend upon dependency_b there's no reason to compile it last... Hence it's no longer strictly reverse order but some sort of mixed order. ;) Yet dependencies are still shown in reverse order.
(In reply to comment #2) > You failed to tell us but I assume you're using portage-2.1.2. Heh, I didn't notice it was in the summary. ;) But anyway this isn't a bug. It's the result of a major improvement of the underlying code (see bug #147766 for details). It is, however, a change in behaviour since portage-2.1.1.
*** Bug 161538 has been marked as a duplicate of this bug. ***
Please reopen, as there's still something wrong. When I do "emerge -vat euses aria2 curl", emerge prints: These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild N ] app-portage/euses-2.5.4 16 kB [ebuild N ] net-misc/aria2-0.9.0-r1 USE="ares bittorrent gnutls metalink nls ssl" 397 kB [ebuild R ] net-misc/curl-7.15.5 USE="ares* gnutls* idn -ipv6 -kerberos -krb4 -ldap ssl test*" 1,507 kB [ebuild N ] net-dns/c-ares-1.3.2 323 kB Emerge writes, that packages will be emerged in REVERSE ORDER, so c-ares will be emerged first. But that's not what's happening - instead, euses will be emerged first. If that's expected behaviour, then at least the emerge message reg. "reverse order" is wrong. askwar@hetzner ~ $ emerge --info Portage 2.1.2_rc4-r8 (hardened/x86/2.6, gcc-3.4.6, glibc-2.3.6-r5, 2.6.17-hardened-r1.03.no-modules i686) ================================================================= System uname: 2.6.17-hardened-r1.03.no-modules i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.12.8 Last Sync: Thu, 11 Jan 2007 06:20:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.3.6, 2.4.4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3, 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.19 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/Gentoo/Portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical" FEATURES="autoconfig buildpkg ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS=" http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://gentoo.itdnet.net/gentoo/ http://ftp.gentoo.or.kr/ http://distfiles.gentoo.org/ " LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/Gentoo/Portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/Gentoo/Portage/build" PORTDIR="/Gentoo/Portage/tree" PORTDIR_OVERLAY="/Gentoo/Portage/local-tree/misc /Gentoo/Portage/local-tree/overlays/nx/nx/testing /Gentoo/Portage/local-tree/overlays/gentoo-de" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 7zip acl apache2 async bash-completion berkdb bzip2 cap caps ccache checkpath chroot cracklib crypt cyrus dcc discard-path dlloader ecc erandom exif extensions firefox glep glibc-omitfp hardened hardenedphp hpn iconv idea idled idn imagemagick imap imlib imlib2 jikes jpeg kdeenablefinal linuxthreads-tls logrotate lynxkeymap maildir mime mmap mmx mmxext mode-owner moznoirc mozsvg multislot nls no-old-linux noaudio nocd nodrm nolvm1 nopop3d offensive pam pam-mysql pcre pdf php pic png posix postfix prelude pyzor razor readline recode reiserfs sasl sendfile server sftplogging sguil sharedmem sse ssl static svg sysvipc szip tcpd threads tiff tokenizer tools unicode userlocales utf8 vhosts vim-pager x86 xfs xinetd xorg zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="void" KERNEL="linux" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="dummy none" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #5) > But that's not what's happening - instead, euses will be emerged first. > > If that's expected behaviour, then at least the emerge message reg. "reverse > order" is wrong. In is expected behaviour as explained in comment #2. Would "mixed order" be better? Or do you have a better suggestion?
I think the current wording is misleading. If everything is working as intended on the back end, perhaps a cosmetic UI update to reflect that there may not be an order at all would help to avoid confusion when portage 2.1.2 goes stable. Something along the lines of "These are the packages that would be emerged, in no particular order" or even "These are the packages that would be emerged" would suffice.
(In reply to comment #7) > I think the current wording is misleading. If everything is working as > intended on the back end, perhaps a cosmetic UI update to reflect that there > may not be an order at all would help to avoid confusion when portage 2.1.2 > goes stable. Oh, there is an order. It's just more complex that "in order" or "in reverse order". Where there are indentations the order is reversed. Where there isn't indentations it's in order... I think that summarizes it correctly.
(In reply to comment #8) > It's just more complex that "in order" or "in reverse order". But that's not what's printed. The statement says, that the pacakges are going to be emerged in reverse order. > I think that summarizes it correctly. No, it does not summarize it correctly. It says: "These are the packages that would be merged, in reverse order:" What does that mean? I understand it so, that now a list of packages is printed. This list of packages shows, which packages are going to be emerged. And the packages are going to be emerged in *reverse* *order*. Ie. "in reverse order" relates to the first part of the sentence. But that's just plain wrong. The packages are NOT going to be emerged in reverse order! See my comment #5 - the list shows "app-portage/euses" first and "net-dns/c-ares" last. If the information printed by emerge were correct, c-ares would be emerged first. However, euses is emerged first. I agree with comment #7 - IMO the best wording would be: "These are the packages that would be emerged". Ie. no reference reg. the order in which the packages are going to be emerged. Maybe it would be useful to indicate, that the order in which packages are going to be emerged doesn't necessarily have to reflect the order in which the packages are printed by "--ask --tree".
(In reply to comment #9) > > I think that summarizes it correctly. > > No, it does not summarize it correctly. It says: [SNIPPED huge rant] You misunderstand. "I think that summarizes it correctly." was referring to the previous two sentences in comment #8. I was just trying to make it clear what expected behaviour is.
(In reply to comment #10) > (In reply to comment #9) > > > I think that summarizes it correctly. > > > > No, it does not summarize it correctly. It says: > [SNIPPED huge rant] What rant? I explained how I understand what's printed, explained why I think it's wrong and gave a suggestion on how the situation might be improved. > You misunderstand. "I think that summarizes it correctly." was referring to the > previous two sentences in comment #8. I was just trying to make it clear what > expected behaviour is. Ah, okay. If it were possible to print all of that in the "emerge --ask --tree" output, than all is fine ;) Until then, I'd suggest to dump ", in revere order" from the output of "emerge --ask --tree", as emerge is not going to do what it says that it's going to do (although that's expected behaviour as I learned now). IOW: emerge says, that the packages are going to be emerged in reverse order. That's not happening. That's a bug (and not a "WFM").
In svn r5965 I've fixed it so that --tree shows the exact reverse of the actual merge order.
Created attachment 110420 [details, diff] make --tree ouput the exact reverse of actual merge order This patch should solve the issue. It will be released in 2.1.2-r10.
This has been released in 2.1.2-r10.
*** Bug 168145 has been marked as a duplicate of this bug. ***
