Summary: | portage-2.1.10.19 is unable to find a gcc update if not explicitly tell | ||
---|---|---|---|
Product: | Portage Development | Reporter: | nobody <noreply> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | major | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info of the host with trouble |
Description
nobody
2011-09-27 20:29:35 UTC
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) |