|Summary:||Update install documentation (handbooks) to use eselect profile for profile switching|
|Product:||[OLD] Docs on www.gentoo.org||Reporter:||Allen Brooker (AllenJB) <gentoo-bugs>|
|Component:||Installation Handbook||Assignee:||nm (RETIRED) <nightmorph>|
|Severity:||enhancement||CC:||docs-team, eselect, ewoud+gentoo, gentoo.integer, mips, raphexion|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Allen Brooker (AllenJB) 2008-08-09 12:05:45 UTC
I would like to request that eselect be added to stage3 tarballs. When you look at the forums, many of the problems that newbies encounter are caused by incorrectly setting the /etc/make.profile symlink. If eselect was in stage3, the handbook could simply instruct newbies to use eselect profile to set the profile symlink, hiding the implementation complexities. I believe this would significantly reduce problems for new users while not significantly impacting stage3 size.
Comment 1 Andrew Gaffney (RETIRED) 2008-08-09 18:26:39 UTC
The only packages contained in a stage3 tarball are those in the system set. The packages in the system set are the ones required for a basic install. I don't think app-admin/eselect counts.
Comment 2 Allen Brooker (AllenJB) 2008-08-10 22:43:50 UTC
While I understand the desire to keep the stage3 tarball contents minimal, does the argument that the availability of "eselect profile" at the earliest possible stage would (fairly siginificantly, imo) reduce the number of problems encountered by new users not count for anything? If we want to argue definitions, if we rephrase the definition of stage3 / system slightly to "packages required for a basic, easy, successful install", then in my opinion eselect would count. In other words, is there no room for a balance between a basic install, and a basic install without encountering unnecessary problems. The profile symlink is all too easy to get wrong, and it's an implementation detail that users shouldn't really have to deal with (imo). Inclusion of eselect solves this issue with minimal impact (a cursory check of the eselect dependencies shows that it doesn't appear to depend on anything that's not already in system, to my knowledge). If you want to reduce the impact further, what about including it only for the amd64 and x86 stage3 tarballs, which are probably the 2 most common stages used by new users.
Comment 3 Thilo Bangert (RETIRED) (RETIRED) 2008-10-07 13:30:18 UTC
on my system eselect fills 58 files and around 200k. IMHO eselect is a good addition to the stage 3.
Comment 4 Andrew Gaffney (RETIRED) 2008-10-07 13:39:19 UTC
So, propose it to -dev. As long as there are no major objections, add it to profiles/base/packages (I think).
Comment 5 Michael Evans 2009-06-16 20:56:52 UTC
I agree, eselect is a good tool to have in stage 3. It is the tool that we should be using to consolidate management of default library, compiler, API, and other similar selections. It's been quite a while since I've had to reinstall a gentoo system, but it would make sense to include (console mode) system management tools unless there is good reason -not- to.
Comment 6 Allen Brooker (AllenJB) 2009-07-01 20:39:23 UTC
As an update to to this, now that stable portage depends on eselect-news, eselect is included in the stage3 tarball. All that needs to be done is to update documentation (handbooks, quick-install guides?) to use it for profile switching.
Comment 7 Xavier Neys (RETIRED) 2009-07-01 21:13:14 UTC
(In reply to comment #6) > eselect is included in the stage3 tarball. Ah, that's good news.
Comment 8 nm (RETIRED) 2009-07-23 03:53:12 UTC
*** Bug 278792 has been marked as a duplicate of this bug. ***
Comment 9 nm (RETIRED) 2009-09-12 17:25:02 UTC
*** Bug 284688 has been marked as a duplicate of this bug. ***
Comment 10 nm (RETIRED) 2010-07-19 06:12:16 UTC
I fixed the handbooks some time ago to use eselect; all except mips. MIPS folks, any word on getting eselect into your stage tarballs?
Comment 11 nm (RETIRED) 2010-07-21 02:33:03 UTC
Meh. All other arches are fixed. MIPS is such a special arch it needs to be treated differently. It doesn't release on the same schedule, and its 10.0 toplevel profiles are very different from the other arch 10.0 profiles. I'll deal with MIPS later.