Sven Vermeulen posted on Sat, 08 Dec 2012 20:41:42 +0000 as excerpted: > On Fri, Nov 30, 2012 at 10:44:31AM -0500, Richard Yao wrote: >> On 11/30/2012 06:46 AM, Sven Vermeulen wrote: >> > On Nov 29, 2012 10:24 AM, "Markos Chandras" <hwoar...@gentoo.org> >> > wrote: >> > > > We could slightly simplify the handbook installation procedure if >> > > > we told people to use emerge-webrsync to fetch the initial >> > > > snapshot. What do people think?
> Okay, I've updated the instructions. > Second, the Portage tree snapshots are now installed through > emerge-webrsync (which means the entire section on downloading the > tarballs, checking integrity, extracting is now a single paragraph). Thanks, swift. =:^) > Finally, the section on updating the Portage tree (using emerge --sync) > is now marked as optional, with the remark that if you're behind a > firewall you can safely ignore this section as the user will already > have a quite up-to-date tree installed. > > I don't know if we should remove the section altogether (about emerge > --sync) or not. It is a small step and users *will* create bug reports > about it if they don't notice it in the documentation anymore. Marking > it optional seems to be a good approach here. ++ on optional. IMHO, one of the finer points of a good handbook-based install is that it "sets the user up for success" by encouraging correct routine maintenance practices in the future, stepping them thru the process once during the initial install. Unfortunately, there's /way/ too many users that read only the handbook's install section (and perhaps Working with Gentoo) and never read the rest, so instilling at least some minimal basics of good routine practices there is important. Thus, even if the webrsync process grabbed them a reasonably fresh (24 hours) initial tree, keeping the now optional section on updating the tree to the very latest is a good idea, since even if it's optional, it'll step the new user thru the process at least once, establishing a good idea of that routine basic as a good practice for future updates. ... For the same reason (but likely more controversially), I'd actually argue that the install section should (optionally?) step thru installing gentoolkit and running revdep-rebuild and emerge --depclean (with an appropriate --ask/--pretend first) as the (near) final steps of the initial install, as well, even if gentoolkit is the only thing in @world when they do so, and it's technically unnecessary as there should be nothing to rebuild or depclean. For depclean especially, establishing the practice right at the beginning will help to ensure that @world always contains all desired "leaf" packages, and that as a result, users will never accumulate a huge backlog of "uncovered" packages subject to getting stale due to lack of @world updating, and that an initial depclean run when they DO get around to it won't "accidentally" uninstall half their system, because it never got in @world to begin with. (Of course, a successful emerge run now includes a helpful depclean reminder anyway, but stepping the user thru the process once during the initial guided install certainly can't hurt.) A quick review of the installation section in the manual suggests either covering this as part of chapter 11, Finalizing your Gentoo Installation, or instead, inserting it as chapter 11, bumping the current 11 and 12 to 12 and 13. I'd suggest the latter, with a title for the new chapter 11 of something like "Your first emerge --update @world". It could encourage readers to look at the working with gentoo and working with portage sections for more, but would be an initial step-thru of a basic emerge --update @world and related maintenance (allowing a condensing of the corresponding chapters in the other sections), for those who never read past install in the handbook. Additionally, with such a title it'd be easier for users to refer back to (and see the encouragement to read the other sections again, when they maybe have more time to do so) for their second update, etc, if they needed to. One more suggestion while I'm at it. I remember all those many years ago when I first installed gentoo, even after reading and absorbing the handbook well enough to be pointing people to specific chapters and subchapters in answer to specific questions on the user list, I was still somewhat confused about the exact nature of the world list, and what packages should be listed there vs. those that shouldn't. Unless I've overlooked it, to this day there's still not a real good explanation of the distinction between "leaf packages" and dependencies, and why "leaf packages" belong in @world but dependencies don't. Something along the lines of: """"" If you want to use and care about that specific package, put it in the world list with emerge <package>, without --oneshot. If you don't really care about that specific package and it's simply pulled in by something else that you DO care about, but you happen to be specifically emerging it anyway, use emerge --oneshot <package>, so it doesn't end up in the world list and emerge --depclean can unmerge it in the future if the packages pulling it in no longer need it. """"" (Actually, here, all my default emerge stub-scripts use --oneshot by default. I use a special "2" (not oneshot) version when I WANT something added to @world, which for me is a sort of package testing purgatory between "I for sure want to keep it and it's in a set listed in world_sets accordingly" and "I'm not sure I really want to keep it yet and thus want to be reminded about it the next time I update and then run depclean --ask to cleanup.") As a result of my confusion, I ended up with more packages in the world list than I really needed/wanted, and somewhere along the line, I had to use some tool (I guess it'd be emaint --clean world, now) to weed out the unnecessary cruft in my world list. (Later, with kde4 and portage 2.2 with sets support, I actually went thru and broke my world file into about a dozen individual sets by functional category, starting with the kde sets which I sync to those in the kde overlay with every 6-month kde4-minor bump, but also including sets such as net-admin with traceroute, etc, and net-user with firefox, etc. This was actually as a result of sorting out my existing world list to copy it to my netbook, but I've kept everything in sets since then, and I've run with an empty world list for about three years now, since everything is in sets as enumerated in my world_sets file. That practice keeps the sets that replace my world file REAL clean, since everything listed is in its own functional category and each set is small enough it's immediately clear upon cat-ing the set whether every package listed in the set is something I actually care about or not. (For the kde sets I keep synced with the ones in the overlay, I comment out the libs and apps I don't need or care about, but keep them in the set, commented, for easier syncing with the overlay versions at the next six-month bump.) I'm really looking forward to the day when proper sets support appears in stable portage, and sets can eliminate the unsorted world list mess for others just as they have for me. Unfortunately, that looks to be something of a "bluesky" enhancement bug for stable or even ~arch, but at least 2.2's there to be unmasked for people who like me have real, practical use for sets.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
