on my host that is running gcc-4.4.2 i have allow updating gcc to 4.4.3-r2 but portage never find it could update gcc to that version for some unknown reason. my configuration is a bit tweak, but i don't see any reason why portage cannot handle that. Reproducible: Always Here's the full story : I have a server that export its package.mask that will be use that the computer that is in trouble with updating gcc. I know this might not be really usual, but there's no real reason portage cannot handle that and behave strange. the server is also an rsync server, and my computer sync with it, so both computers use the same tree version. to make things easier i will never output anything from the server so none can mistake of what computer i'm speaking: so only output anything from my desktop that is showing the problem. my package.mask is set as-is : ls -l /etc/portage/package.mask lrwxrwxrwx 1 root root 38 16 sept. 2010 /etc/portage/package.mask -> /mnt/faramir/portageshare/package.mask cat /etc/portage/package.mask >sys-devel/distcc-4 >sys-devel/gcc-4.4.3-r2 >sys-kernel/linux-headers-2.6.38.7 >sys-libs/glibc-2.12.1 emerge -pCv gcc * This action can remove important packages! In order to be safer, use * `emerge -pv --depclean <atom>` to check for reverse dependencies before * removing packages. >>> These are the packages that would be unmerged: !!! 'sys-devel/gcc' is part of your system profile. !!! Unmerging it may be damaging to your system. sys-devel/gcc selected: 4.4.2 protected: none omitted: none As you see i only have 4.4.2 install here : Now the strange part emerge -upv gcc These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items. beleg portage # emerge -upv gcc:4.4 These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items. emerge -pv gcc These are the packages that would be merged, in order: Calculating dependencies... done! [binary R ] sys-devel/gcc-4.4.2 USE="fortran gtk mudflap nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -graphite (-hardened) (-libffi) (-multilib) -multislot -nocxx -objc -objc++ -objc-gc -test -vanilla" Total: 1 package (1 reinstall, 1 binary), Size of downloads: 0 kB * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items. Portage is not able to see there's a possible update to gcc But if i ask emerge -upv =gcc-4.4.3* These are the packages that would be merged, in order: Calculating dependencies... done! [binary U ] sys-devel/gcc-4.4.3-r2 [4.4.2] USE="fortran gtk mudflap nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -graphite (-hardened) (-libffi) (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla" Total: 1 package (1 upgrade, 1 binary), Size of downloads: 0 kB * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items. This time not only portage agree to upgrade gcc, but it even respect the package.mask and offer to upgrade to the correct 4.4.3-r2 version, keeping version as package.mask was set. I keep my gcc/glibc... under a global package.mask, so only when the server allow an upgrade, all my hosts upgrade their toolchain, easier to maintain, and i must keep my versions close as all hosts are part of the distcc process. My server already upgrade its gcc to 4.4.3-r2 (i could even upgrade it more, there's a 4.4.3-r3 and more gcc version 4.5* and even 4.6* in my tree) But for some reason, portage cannot detect that upgrade if i'm not asking it using the =gcc-4.4.3*
Created attachment 287981 [details] emerge --info of the host with trouble
For me it's -k that gave the trouble as the 4.4.3-r2 binary doesn't exist yet, but portage man say -k should work as expect (not like the -K) --usepkg [ y | n ] (-k short option) Tells emerge to use binary packages (from $PKGDIR) if they are available, thus possibly avoid‐ ing some time-consuming compiles. This option is useful for CD installs; you can export PKGDIR=/mnt/cdrom/packages and then use this option to have emerge "pull" binary packages from the CD in order to satisfy dependencies.
The behavior that you describe it intended for cases in which the sys-devel/gcc-4.4.3-r2 source ebuild does not exist in the portage tree. For example, see bug #233253. A similar case also occurs, for example, when the version scheme of an ebuild transitions from $YEAR$MONTH$DAY format to a more usual 1.2.3 format. In cases like this, the older installed versions appear to be "newer" when normal version comparison rules are applied. It's not really practical to maintain package.mask entries (forever) in order to force pseudo-downgrades of this sort. Anyway, the short answer is that you should use --usepkgonly/-K if the source ebuild does not exist in the tree.
I'm not downgrading gcc, i just keep my gcc version mask until i need a new one, so everyone could then upgrade upto the new mask. So, it's not a downgrade problem. And my both tree are sync as my server is the rsync of my desktop tree. And that gcc ebuild exists (you just have to check your current tree to see it) ls ChangeLog gcc-4.0.4.ebuild gcc-4.4.5.ebuild Manifest gcc-4.1.2.ebuild gcc-4.4.6-r1.ebuild files gcc-4.2.4-r1.ebuild gcc-4.5.1-r1.ebuild gcc-2.95.3-r10.ebuild gcc-4.3.3-r2.ebuild gcc-4.5.2.ebuild gcc-2.95.3-r9.ebuild gcc-4.3.4.ebuild gcc-4.5.3-r1.ebuild gcc-3.1.1-r2.ebuild gcc-4.3.5.ebuild gcc-4.6.0.ebuild gcc-3.2.2.ebuild gcc-4.3.6-r1.ebuild gcc-4.6.1-r1.ebuild gcc-3.2.3-r4.ebuild gcc-4.4.2.ebuild metadata.xml gcc-3.3.6-r1.ebuild gcc-4.4.3-r3.ebuild gcc-3.4.6-r2.ebuild gcc-4.4.4-r2.ebuild
lol my bad, mistake 4.4.4-r2 with 4.4.3-r3, i will try to higher my mask to add r3 in it.
ok, it work if i put 4.4.3-r3, that was the missing ebuild indeed. Thank you for your answer zac
I suppose we could add a warning message when binary packages are ignored for this reason, similar to the warning that we added for bug #297549.
I would like to add a few more comments that i find interresting : Removing -k didn't change it: portage cannot update gcc to 4.4.3-r3 because of my package.mask setting and indeed my server was using that ebuild from a previous sync (i keep generally two gcc: one for use with others hosts as distcc provider: my "stable" gcc, and a newer one i kept on server until i decide it's the new stable version to use, i then higher the package.mask so it met my new gcc version and all my hosts can build it and use it then) The real problem is that 4.4.3-r2 was remove from the tree and 4.4.3-r3 was present. But (with my "stable gcc" habit, i higher the package.mask to use 4.4.3-r2 only and not -r3 that i didn't test on the server). Portage was now in a deadlock: it cannot upgrade to -r3 because of package.mask and cannot upgrade to -r2 simply because there's no more -r2 ebuild). I clearly see my mistake now and why portage couldn't upgrade gcc: and when i check (didn't think of that case at first) the 4.4.3-r2 presence when you speak about that possible cause i mistake 4.4.4-r2 for 4.4.3-r2: another error, and if 4.4.3-r2 was present like i suppose : then portage was misbehaving. But 4.4.3-r2 wasn't present, i'm sorry for the confusion :( There's still something i find strange, but i think i could easy reproduce it and will try to do it before speaking about something i'm not totally sure (eheh this time i will took a better care of what i'm doing)
