I have been bitten by the problem described on thread http://forums.gentoo.org/viewtopic.php?t=166696 which lists the bug #49363. This is one instance of this kind of problem: Whenever the Core System gets badly broken, like the binutils+gcc problem above, the system gets unable to heal itself. It needs to be fixed from the outside. If we had binary packages at least for the Core System, we would be able to heal the system on these cases. AND, since we have a GRP anyway, it might not be unfeasible to provide the binaries to the latest stables as well, unbundled from the bulky CD images and untied to the Gentoo Releases. Reproducible: Always Steps to Reproduce: 1. Bork something like the compiler 1.1 You can simply run emerge -u world and have some downgrade mess up with your system. 2. How do you reemerge without gcc or a binary package? 3. I have posted as a bug instead of enhancement because it is very serious for users which have their systems unable to update.
Why can't you just recover off the Gentoo Live cds?
This is a good idea. Especially if file system corruption wipes out a number of say, glibc files, then you're screwed. I had this happen when some bad ram was cauing my scsi disks to lose parity and reiserfs started going senile. Took several days, and I had to get a bin package of glibc off someone before I could get the system back on its feet and have it re-merge everything. Eithercase, probably an idea to consider is having core system packages, like gcc/binutils/glibc auto-build binary packages of themselves after a successful emerge. That way they're always available if something breaks (just hope fsck doesn't delete them).
I maintain a repository of recovery binaries with a README at http://dev.gentoo.org/~avenj/bins for this reason. Perhaps they should go on mirrors or at least get documented somewhere obvious, though.
There are two issues being discussed here: 1. How to recover your system in case of emergency, such as the base system getting corrupted. 2. Providing binary packages on an ongoing basis for the core system. avenj already provides binaries for #1 and I agree we can probably document that better and/or make them more available on our mirrors. As for #2, that is completely out of our purview and will create more problems than it will solve. We do not want to get into the business of trying to support binary versions of GCC on an ongoing basis. We should only offer GCC binaries for emergency purposes, such as outlined in #1. For reasons why, please see http://dev.gentoo.org/~rac/binaries.html
Let me emphasize again: Since Gentoo already provides binaries on the LiveCDs, how is it unfeasible to provide them outside the LiveCDs? I know that i am suggesting that we should have binaries for the lastest system, and that can be much more than one compilation every month. BUT, I am also saying: Let's stick these binaries to the GRP, the GRP has a standard and unchangeable set of USE flags, doesn't it? Binaries compiled with a single difference on the USE flags would not be considered GRP. I believe CFLAGS have similar limitations. We would need a single 'builder' for a single package for each arch, and not for every package, only for the core ones. The single thing that may set back this is CPU, but many people that lack enough knowledge to be programmers can still build packages using 'emerge --buildpkgonly foo'. As long as they stick to the USE and CFLAGS when they build this package, it should conform to the GRP standard, and should work on every Gentoo install. I can build something, even though I am not (yet) a developer. Many people can volunteer to be 'builders'.
Additionally, portage can display a warning like: You are emerging a 'Core Binary Package'. This binary package is strictly conforming to the Gentoo GRP, so it may not be using your USE and CFLAGS settings. You might want to recompile this package if you want it fully optimized to your system. If you are restoring functionality because of a BROKEN EBUILD, make sure the ebuild has been fixed before recompiling this package. If you are installing a fresh system, you may safely ignore this message. Optionally, we can remove the word 'Core' and stick this warning to every binary package that the user installs.
If I need to set up a User Mode Linux environment to build strictly GRP packages, I will. I am using an Athlon XP 2600 with 512 MB of ram, and a 120GB hd. it is midrange by todays, standards, but it still packs enough power to build stuff.
if you "stick" the binaries to the latest GRP, you are essentially assuming nobody who ever uses GRP will ever 'emerge -u world' to upgrade their system to a non-GRP state. Let me emphasize again: we're discussing two different issues. emergency recovery and providing ongoing binaries of the core system. We already do the first and we can do more to publicize that fact. Trying to do the second is infeasible for the reasons I've already mentioned. Please read that binaries.html page in-depth if you haven't done so already. It articulates the problems associated with mixing binaries and source-based packages quite well.
Kurt said: If you "stick" the binaries to the latest GRP, you are essentially assuming nobody who ever uses GRP will ever 'emerge -u world' to upgrade their system to a non-GRP state. No, at least to my understanding of what GRP is. My understanding of the term GRP is that the GRP is a set of programs and build procedures, but I am considering that a newer (latest stable) version of one of the packages, if it is built using the USE and CFLAGS outlined by the GRP, it will be too a GRP compliant package. Under the scope of my understanding of what GRP is, I am not implying what you stated. And in your definition I understand that the GRP packages are tied to the Gentoo Releases and there are specific versions, so even if I use the same USE and CFLAGS, but instead use the latest binary, that would not be GRP. Maybe I am still not getting the *official* meaning of GRP, but now you understand what I mean? I think that the best solution to the user would be: emerge recover system or, if the user knows which package is wrong: emerge recover binutils gcc and he would have the *binaries* downloaded and installed. Maybe with the warnin I suggested above at the end of the emerge, or something like it? I hope we are getting closer to an understanding, and thanks for all the developers to the clarification. One last question: Do we have a page with an official definition of what GRP is?
GRP has one purpose -- to allow users to install gentoo quickly. It is *not* intended for ongoing usage. Moving from one GRP version to a newer version of GRP is not (and has never been) supported. If you start mixing pre-compiled versions of GCC/glibc with applications compiled against older versions of GCC/glibc, you're inviting all sorts of problems.
Ok, Kurt, I bow to your definition. By the way, I used Jon's binaries to fix my system. It is healty now. Thanks, Jon. Now, what about having those binaries easily accessible to users grieving for their systems? How about my suggestion of 'emerge recover'? My problem is fixed now, I am thinking of what is the best way to help users fix their system, when something very basic breaks up. Shall this bug be closed and a new one opened, 'wishlist: add emerge recover to download Jons binaries'?
I don't see a problem with providing a set of binary packages. The only problem is the slippery slope we get into as we start supporting non-x86 arches. Do we need both multilib and non-multilib binaries for amd64? sparc? mips? Also, why does nobody take into account that you are always capable of unpacking a stage3 tarball (or even stage2 or stage1) over your existing installation to recover? Why do we need to provide everything again?
Many people have unpacked stage3 tarballs on / to fix a broken gcc, only to iscover that they get lots of segfaults as they basically downgraded glibc. I very much prefer providing updated binaries like avenjs bins instead. In fact, I'll be happy to set this up for alpha.
re comment 12, unpacking a stage3 tarball: You have to be *very* careful when you try to do this on a running system. The stage tarball contains things like /dev/, /etc/ and /var/db/ which you really don't want to overwrite what you have. Especially /var/db/ can cause all kinds of fun problems. If the glibc in the stage tarball is the same version as what you have, it'll overwrite CONTENTS which means portage will "forget" about the presence of any files the users glibc installed that are not also in the stage tarball (think different USE, /etc/locales.build etc). If the glibc in the stage tarball is *older* than what is on the system you'll end up having two glibc's in the same slot. When you then emerge *anything* it'll autoclean *the glibc from the stage tarball*. Boom, now you don't have a glibc anymore. The same of course happens for every other package in the stage tarball. I have seen this happen to someone on #gentoo at least once. I usually recommend people to grab binary packages from dev.gentoo.org/~avenj/bins. This is a lot safer than taking things from a stage tarball, as it allows portage to track things properly (if you can still use emerge) and it makes it easy to use a binary package for just one broken package, not the entire base system. Back on topic, something I just thought of: would it be feasible for portage to automagically build packages when you build things in "system"? Perhaps keep a backlog of a few binary packages per base sytem package? That would provide the user with the ability to "fall back" to a binary that worked before, on his system. Haven't thought about this a lot, but perhaps it would work?
re #13: The method of doing such a recovery would be to unpack the stage, do an emerge sync, then update world. People shouldn't be sticking with the contents of he stage3 tarball. Like I said, they could also use the other stageballs, which would probably be the best thing. re #14: FEAUTRES="buildpkg" works pretty well for exactly this, and it keeps all versions unless you specifically remove them. The only downfall is there is no way to limit this to just "system", but I could see that being a good feature request of the portage team. While I understand the reasoning behind providing the individual packages, I simply don't think it should be something that we should be providing, as it will end up being something that we have to support. Already this is falling under the "release" area, when it has nothing to do with releases, but rather system recovery. I understand why it is put under releases, but you can see my point. I am already having to deal with it, and it hasn't even been done yet... ;] Anyway... I don't think that we should be providing binary packages. We are even moving away from the binary packages of GRP to a more elegant solution in the future. If we simply provided the packages that we used in building the LiveCD, then it would still be a "basically downgraded glibc" unless we decided to start producing packages for every glibc we have in portage.
I should have done this a while back. I have no intentions on doing anything to fix this, in regards to the releases. If someone else from another team wants to take this, then they can REOPEN it.
Well, why not have the binary package built locally? GGC and the toolchain are compiled and installed, and a copy optionally kept locally (on an unmounted filesystem, a DVD or something.) Then, if something goes wrong, you emerge (or some other tool) maysimply copy a working compiler & toolchain from the backup.
