Summary: | ppc64 32bits userland profile changes led portage to want an impossible glibc downgrade | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Frederic Grosshans <frederic.grosshans_web> |
Component: | [OLD] Core system | Assignee: | ppc64 architecture team <ppc64> |
Status: | VERIFIED WONTFIX | ||
Severity: | blocker | CC: | jakub, vapier |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | PPC64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 138446, 139185 | ||
Bug Blocks: |
Description
Frederic Grosshans
2006-07-04 03:28:39 UTC
Downgrading glibc is always impossible, so... shrug, fix the real bug, don't downgrade. Sorry. If someone masked gcc-4.1, then glibc-2.4 should have been masked as well as it depends on it - but I see glibc-2.4-r3 and gcc-4.1.1 keyworded stable on ppc, so really I don't grok what are you talking about. (In reply to comment #1) > > If someone masked gcc-4.1, then glibc-2.4 should have been masked as well as it > depends on it - but I see glibc-2.4-r3 and gcc-4.1.1 keyworded stable on ppc, > so really I don't grok what are you talking about. It was a 32ul problem : on ppc, both have been marked stable and masked in the 2006.0 profile simultaneously. They have only been masked later in the 32ul ppc64 profile, hence this bug. I've upgraded to gcc 4.1 and glibc 2.4, met bug 138446, which has been "solved" by this change in the 32ul ppc64 profile, hence the "impossible but necessary downgrade" for some people. (In reply to comment #1) > Downgrading glibc is always impossible, so... Sad, but I guess the lif is sometimes sad... > shrug, fix the real bug, don't > downgrade. Sorry. An acceptable resolution (for me) would be unmasking gcc 4.1 and glibc 2.4 , in an experimental 2006.1 profile, like in the ppc32 2006.1 profile. Do you still object to the dependency of bug 138446 to this bug ? Bug 138446 has basically been solved for everyone, except for the people like me, because of this impossible but necessary downgrade. (In reply to comment #3) > Do you still object to the dependency of bug 138446 to this bug ? Bug 138446 > has basically been solved for everyone, except for the people like me, because > of this impossible but necessary downgrade. Erm, what dependency? I haven't noticed any, adding it now. :) Looks like this is related to http://article.gmane.org/gmane.linux.gentoo.releng/429/ - well this upgrade path is _very_ broken, should never have happened. Masking of core toolchain packages in profiles resulting in forced glibc downgrade should never ever be done. :=( I don't think this is a ppc32 problem, just a ppc32 ul on ppc64. I'm reassigning to ppc64. :) this reminds me, i need to add a check to the glibc ebuild to prevent users from downgrading their glibc (In reply to comment #6) > this reminds me, i need to add a check to the glibc ebuild to prevent users > from downgrading their glibc Agreed. However, the bug is not that this downgrading is impossible, but also that the evolution of stability of glibc-2.4 and the evolution of the 32ul ppc64 profile have forced some users into this impossible downgrade, with no clean way out. That's why I reopen the bug, waiting for a fix allowing a glibc upgrade. you seem to think there is supposed to be a way to downgrade in your own low message you showed why it cant happen: version `GLIBC_2.4' not found (required by /usr/lib/libsandbox.so) that means sandbox was built against glibc-2.4 and it *cannot* work against anything older than that ... sandbox isnt the only thing that'd be broken in other words, it's never going to happen come up with real fixes for the real bugs, stop trying to invent wrong solutions for things that arent bugs Following an offline email exchange with SpanKY, I changed the title of the bug (avoiding the confusion on my intention to downgrade glibc). The workaround to override the profile (tahnks SpanKY !) is to create the file /etc/portage/profile/packages with the following lines -<sys-libs/glibc-2.4 -<sys-devel/gcc-4 I close this bug, since it was caused by a transient change of the profiles, and a workaround has been found ( comment #9) |