Here's guidexml-ization of the chost changing guide that amne posted to gentoo-dev. Consider it a draft. Passes xmllint and comes up just fine on dev.g.o, which I know doesn't mean it's perfect ;). Rendered preview is in the URL field.
Created attachment 96906 [details] change-chost.xml
IMHO, it would be a lot more useful to our users if we used a move from i386 to i686 as an example as that is the most common occurrence. It seems many users used an x86 stage3 instead of the i686 one and need to switch to i686 to keep upgrading.
(In reply to comment #0) Minor GuideXML issues, but no real problems there. However, this mini-howto absolutely must have a short preface explaining why one might need to change CHOST -- basically, repeat the summary off to the side, but expand on it more. Changing CHOST is never something to be undertaken for the hell of it. Also, it is an absolute CERTAINTY that users will need to recompile world after changing CHOST. I've dealt with users for a straight year that changed CHOST without recompiling world and seen all the problems that result from this. It is not a "may" or "advisable"; it is *critical* that users run emerge -e world after changing CHOST. This doc should not go in without that part of the guide being changed to reflect this necessity. Other than that, hey, it's a good start. :)
i really dont think so ... some specific packages have issues (and are mentioned in the guide), but in general packages should not care
(In reply to comment #4) > i really dont think so ... some specific packages have issues (and are > mentioned in the guide), but in general packages should not care > I disagree. I've had an additional year of experience on a project outside of Gentoo (Jackass) in which I've seen countless users bork their systems trying to change (for example) from i586 to i686 without recompiling world. A single emerge -e world is a small price to pay for getting to your desired CHOST. If users really want to change CHOST, then they cannot get around this step. This guide needs to include this step as a requirement, not as a suggestion.
i dont really accept a "wealth" of experience on the forums with users using a ton of different and wrong instructions valid experience
(In reply to comment #6) > i dont really accept a "wealth" of experience on the forums with users using a > ton of different and wrong instructions valid experience > Except that you really don't know how the Jackass! project works, do you? The installation instructions were the Gentoo handbook, since all that the project offered was a vanilla stage3 tarball that was built with and contained (at that time) ~x86 toolchain packages, namely gcc 3.4. So get off the "wrong instructions" platform. If the Gentoo packages don't work right after changing CHOST, and if they do work by running an emerge -e world right afterward, then emerge -e world goes in. That is the fix. You can't try to switch from gcc 3.4 to 4.1 without recompiling, lest you end up with a mishmash of packages built in funny ways, and you can't try switching CHOSTs without running into the same result. Besides, the forums are where users report what's wrong with Gentoo packages and build systems, not IRC. Respectfully, you're not active on the forums, so you don't see the how the vast majority of the user community tries to figure out solutions. Re-emerging world after changing CHOST is a time-tested solution to avoiding system b0rkage on down the road. This guide will include that step -- I guarantee you that a simple recompile of two packages won't fix things.
no, i have no idea how the Jackass project works nor do i care i didnt say anything specific, i said that there is so much wrong information floating around the forums that i dont trust any of it rebuilding with a different CHOST is not the same thing as a gcc upgrade and unless the gcc upgrade is an ABI change, moving forward is safe as well without rebuilding world
Thanks Chris for xmlification! (In reply to comment #2) > IMHO, it would be a lot more useful to our users if we used a move from i386 to > i686 as an example as that is the most common occurrence. Good idea, done that. Perhaps someone can proof-read it in case it became inconsistent, but it looks good to me. (In reply to comment #3) > However, this mini-howto absolutely must have a short preface explaining why > one might need to change CHOST -- basically, repeat the summary off to the > side, but expand on it more. Changing CHOST is never something to be undertaken > for the hell of it. Rearranged some stuff from the abstract and added an introduction. As for recompiling world, some packages were added and i think the guide should catch the most common pitfalls with the CHOST migration (e.g. the perl packages). No one is forcing the users not to recompile their world target, let's just give them a chance to make their own decisions.
Created attachment 97342 [details] new version New version, can be viewed online on http://dev.gentoo.org/~amne/temp/change-chost.xml
Created attachment 97343 [details] some more fixes
Created attachment 97365 [details] another one... i owe you a cookie vapier.
Created attachment 97820 [details] New version New version, Orin Eman reported some problems when upgrading CHOST and gcc at the same time, so i've added a warning not to do that and an explanation from Mike why it doesn't.
Would have been done quicker if I hadn't had to pay special to silly things like "master of wang". Valid XML is always appreciated btw. Please do use xmllint. In CVS. You can already see it at http://gentoo.neysx.org/doc/en/change-chost.xml or wait for the next sync on www.g.o You might want to redirect from your versions on woodpecker btw. Thank you all for your work.
(In reply to comment #14) > Would have been done quicker if I hadn't had to pay special to silly things > like "master of wang". Sorry for that silly joke, i couldn't resist. > You might want to redirect from your versions on woodpecker btw. Definitely. > Thank you all for your work. Thanks, too!
Do we want to leave the "Feedback" section as-is?
