Hi All... Well, it's that time again... I've done a whole heap of updates to the handbook, which can be viewed on my server at the URL mentioned above. The main updates were: - Bootloaders section: o tentatively removed the sections on arcboot - Kernel section: o removed the discussion regarding USE flags (I assume this is handled by the profiles) o added new section covering the profiles, and how to switch them As always... if you spot any errors, or think something could be done better, let me know. I'd like to get things sorted before the docs go live officially. Regards, Stuart Longland.
Looking it over a wee bit, I'd say Parts A and B from Chapter 7 needs to be moved to Chapter 6, as their not really part of the Kernel install. Plus 7B's info clashes with info provided in 6B, so 7B should outright replace it, actually. Change nptl from "highly-experimental" to something like, "in-testing". It actually works decently. This is in contrast to n32, which is very much "highly experimental". Probably nptl can become yellow warning, while n32 remains red. The profile breakdown, Maybe that can be put into a table? The list works, but looks a little mismatched to my eye. I'll leave this one up to you, though. I would also not refer to n32 as "partial 64-bit"...I dunno if that's even accurate really. Probably good to just call it "N32 Userland Profile (Linuxthreads) [Testing]", and the nptl one "N32 Userland Profile (NPTL) [Testing]". Same for O32, except "O32 Userland Profile (Linuxthreads) [Default]", since that's the current one everyone uses. By the time n32 even becomes functional for the average joe, NPTL will probably be the de-factor threading model anyways. Equally for n64, "N64 Userland Profile (blah) [Unsupported]", where Blah is Linuxthreds or NPTL. Code Listing 2, setting the profile, reference the generic-be/o32 profile instead of ip28. Most people will be using this, so I don't want those who can't read to file bugs wondering why ip28 sources are being merged into their O2. Go ahead and remove the reference(s) to gcc-mips64 and replace it with sys-devel/kgcc64. I'm gonna deprecate gcc-mips64 VerySoonNow(TM) and replace it in the system profiles with kgcc64. ---- About it for now, I'll check for other things leater. Great work Stuart!
(In reply to comment #1) > Looking it over a wee bit, I'd say Parts A and B from Chapter 7 needs to be > moved to Chapter 6, as their not really part of the Kernel install. Plus 7B's > info clashes with info provided in 6B, so 7B should outright replace it, > actually. Okay... to address this, I've created a new MIPS-specific section, hb-install-mips-system.xml. Much of the content is similar, except where it lists the profiles. This will naturally be attached to the bug so it can be added to the CVS repository, when it becomes time to commit. In the meantime, docs-team, you may wish to have a look at <http://stuartl.longlandclan.hopto.org/~stuartl/gentoo/docs/gentoo-doc/en/handbook/> as this is what I'll be sending you in patch-form later on. :-)
(In reply to comment #2) > Okay... to address this, I've created a new MIPS-specific section, > hb-install-mips-system.xml. Much of the content is similar, except where it > lists the profiles. In which case you really don't need yet another separate file
(In reply to comment #3) > (In reply to comment #2) > > Okay... to address this, I've created a new MIPS-specific section, > > hb-install-mips-system.xml. Much of the content is similar, except where it > > lists the profiles. > > In which case you really don't need yet another separate file > Errr.... Yes we do. (1) because there's x86 and PowerPC-stuff in the generic one which has nothing to do with MIPS and (2) because there's MIPS stuff that's nothing to do with the other architectures. It's been this other arch stuff that's traditionally confused some of our less-capable users, and it makes the doc look unprofessional. I wouldn't fork off a separate version of the doc if I didn't think there was a good reason for it. :-)
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Okay... to address this, I've created a new MIPS-specific section, > > > hb-install-mips-system.xml. Much of the content is similar, except where it > > > lists the profiles. > > > > In which case you really don't need yet another separate file > > > > Errr.... Yes we do. > > (1) because there's x86 and PowerPC-stuff in the generic one which has nothing > to do with MIPS > > and > (2) because there's MIPS stuff that's nothing to do with the other > architectures. > > It's been this other arch stuff that's traditionally confused some of our > less-capable users, and it makes the doc look unprofessional. I wouldn't fork > off a separate version of the doc if I didn't think there was a good reason for > it. :-) > Please see any of the x86+amd64-foo.xml docs in /doc/en/handbook/draft/, for example, hb-install-x86+amd64-kernel.xml. Notice that we now implement conditional keys and test for them. So if you're browsing the amd64 handbook (the arch is already set), you see things that don't appear for x86 viewers, and don't see things that are x86-only. Yet it's all pulled from the exact same xml file; we just do a test to see which one you should see. This is why you don't have to do a separate MIPS doc just for this stuff, unless it's extremely extensive. It's not hard to add in all the MIPS content to an existing doc, and all we have to do is add the proper arch evals to determine what gets shown to the user. I think this is what neysx has in mind.
Per bug 101034 , please *remove* the following text from hb-install-mips-disk.xml: "It has an additional hashed b-tree indexing option that enables high performance in almost all situations. You can enable this indexing by adding -O dir_index to the mke2fs command. In short, ext3 is an excellent filesystem." Just chop it out and leave the first part of the ext3fs description in place. Thanks, stuart!
I pulled the MIPS docs from stuart's website and imported them into handbook/. they'll be going live shortly (all i had to do was take out <tt>, which was not supported by our DTD), so speak now or hold your peace. :)
Okay, it's all in and live in CVS. Ping a GDP member if there's anything else you want in. Good job. Redhatter -- once we recover for a bit, we'll take a look at implementing conditionals for your mips stuff so we can cut down on excess files. in the mean time, this is fine.
Fixed in CVS.
