Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 384717 - portage-2.1.10.19 is unable to find a gcc update if not explicitly tell
Summary: portage-2.1.10.19 is unable to find a gcc update if not explicitly tell
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: x86 Linux
: Normal major
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-27 20:29 UTC by nobody
Modified: 2011-09-28 20:41 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info of the host with trouble (einfo.txt,4.40 KB, text/plain)
2011-09-27 20:30 UTC, nobody
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nobody 2011-09-27 20:29:35 UTC
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*
Comment 1 nobody 2011-09-27 20:30:17 UTC
Created attachment 287981 [details]
emerge --info of the host with trouble
Comment 2 nobody 2011-09-27 20:44:20 UTC
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.
Comment 3 Zac Medico gentoo-dev 2011-09-28 00:40:10 UTC
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.
Comment 4 nobody 2011-09-28 01:16:25 UTC
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
Comment 5 nobody 2011-09-28 01:19:00 UTC
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.
Comment 6 nobody 2011-09-28 01:20:28 UTC
ok, it work if i put 4.4.3-r3, that was the missing ebuild indeed.

Thank you for your answer zac
Comment 7 Zac Medico gentoo-dev 2011-09-28 15:21:05 UTC
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.
Comment 8 nobody 2011-09-28 20:41:51 UTC
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)