| View previous topic :: View next topic |
| Author |
Message |
jmbsvicetto
Moderator
Joined: 27 Apr 2005
Posts: 4734
Location: Angra do Heroísmo (PT)
|
 Posted: Thu Jan 05, 2006 5:29 am Post subject: |
 |
|
First let me start by stating that I' m sorry for misunderstanding you.
In case I gave you the impression that I think everything is "sweet and peachy" with Gentoo, let me contradict that. I agree fully with your desire to have an improved Portage and emerge. Since I would like that emwrap.sh replaces emerge or that it's functionality is biult into it, I think we basically agree on this point. I've just spent two days rebuilding my AMD64 system because of "several" stupid misteaks I made after I had problems with ACL and did the "clever" step of removing ACLs. The result was getting an unseable system! This is one case where I think some RED LARGE WARNING would be very helpful. It's also a pitty that the binary packages for ACL and ATTR have not been built to the AMD64 arch. In any case, it was the sucession of "my errors" that lead me here. I did what I had to, I rebuilt my system, but it surely didn't pleased me much.
About the Stage1 vs Stage3, I personally like Bob Predaina's Stage1/3 method and think that it addresses some of the issues you raise. Bob has gone as far as creating the Jackass! and Rockhopper! projects which help saving a lot of time for those wishing to start with an optimized stage tarball. From your posts, I gather that you're particularly interested in servers. Perhaps you and anyone else in your position, could help Bob creating optimized stage tarballs for servers that support NPTL and remove PAM and NLS if that's what you like.
I think that emwrap.sh is one of the best tools to keep one's system up to date and it seems you've also agreed on its merits. Therefore, the combination of Stage1/3 or Jackass! methods to build a new system and the use of emwrap.sh to keep systems up to date, allows one to avoid the Stage3 method. I also think that these should perhaps be the preferred methods for Gentoo install and maintenance.
I'm also sorry for giving the idea that you didn't help. I'm not a user of the bootstrap script and was unaware of your bug reports, but in any case I didn't meant to give the idea that you were just using it and not helping out. My suggestion for you to help was meant at the Stage1 documentation that is being developed. That's why I talked of Sven Vermeulen, who is a member of the Gentoo Documentation Project.
_________________
Jorge.
Your twisted, but hopefully friendly daemon.
AMD64 / x86 / Sparc Gentoo
Help answer || emwrap.sh
|
|
| Back to top |
|
 |
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 05, 2006 6:24 am Post subject: |
|
|
| jmbsvicetto wrote: | | About the Stage1 vs Stage3, I personally like Bob Predaina's Stage1/3 method and think that it addresses some of the issues you raise. Bob has gone as far as creating the Jackass! and Rockhopper! projects which help saving a lot of time for those wishing to start with an optimized stage tarball. From your posts, I gather that you're particularly interested in servers. Perhaps you and anyone else in your position, could help Bob creating optimized stage tarballs for servers that support NPTL and remove PAM and NLS if that's what you like. |
I started off using Bob's method to get stage3's with nptl, something that was available on no other linux distribution at the time. His current method, however, is actually a stage3 installation. I do install a lot of servers, my main concerns are being able to automate the process that gives consistent results. I wrote my own bootstrap script that automatically handles chost changes and the initial toolchain upgrade when starting from a stage1. I am currently working on an emerge wrapper of my own that splits emerging into 4 targets - toolchain, system, world, and universe. Each target will not touch the other. I also plan on integrating my bootstrap script into it so that it is a one stop shop. Right now it will just do system, world, and universe, without touching toolchain packages. The only problems are that this will probably only work on x86 boxes and will more than likely break when changes are made within portage or to the ebuilds involved... It will probably end up being a waste of time.
| jmbsvicetto wrote: | | I think that emwrap.sh is one of the best tools to keep one's system up to date and it seems you've also agreed on its merits. Therefore, the combination of Stage1/3 or Jackass! methods to build a new system and the use of emwrap.sh to keep systems up to date, allows one to avoid the Stage3 method. I also think that these should perhaps be the preferred methods for Gentoo install and maintenance. |
I agree emwrap.sh provides excellent functionality. I particularly like how cleanly it is written, it is source code to behold 
| jmbsvicetto wrote: | | My suggestion for you to help was meant at the Stage1 documentation that is being developed. That's why I talked of Sven Vermeulen, who is a member of the Gentoo Documentation Project. |
As far as I know, stage1's are created by catalyst. As far as I am concerned stage1's are perfect, it is using them to build an optimized/customized stage2/3 that is a problem If you want to use catalyst, you have to do a custom profile to do anything beyond the cookie cutter desktop-centric stage2/3. Well, I take that back, the broken portage bootstrap script that catalyst uses probably won't let you do it no matter what you do... I digress. Is Sven working on something in addition to bootstrapping that might be interesting? |
|
| Back to top |
|
|
Dlareh
Advocate
Joined: 06 Aug 2005
Posts: 2102
|
| Posted: Tue Jan 10, 2006 2:44 am Post subject: |
|
|
Wow, this thread is chock full of some really classic gentoo fanboy idiocy and lameness.
/me puts some popcorn in the microwave
Carry on..........
_________________
"Mr Thomas Edison has been up on the two previous nights discovering 'a bug' in his phonograph." --Pall Mall Gazette (1889)
Are we THERE yet? |
|
| Back to top |
|
|
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 19, 2006 1:12 am Post subject: |
|
|
| Dlareh wrote: | | Wow, this thread is chock full of some really classic gentoo fanboy idiocy and lameness. |
You aren't joking. Some people are even trying to claim that a stage3 install offers some sort of advantage of a stage1! What idiocy.
For grins I ran a couple of tests. I wouldn't piss on a stage3 install if it was on fire  They deprecated the wrong installation method. |
|
| Back to top |
|
|
omp
Retired Dev
Joined: 10 Sep 2005
Posts: 1018
Location: Glendale, California
|
| Posted: Thu Jan 19, 2006 2:13 am Post subject: |
|
|
Uh oh... This thread has been resurrected. 
_________________
meow. |
|
| Back to top |
|
|
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 19, 2006 4:49 am Post subject: |
|
|
| omp wrote: | | Uh oh... This thread has been resurrected. |
It is Dlareh's fault |
|
| Back to top |
|
|
Master_d
Apprentice
Joined: 12 Oct 2003
Posts: 152
Location: Milwaukee
|
| Posted: Thu Jan 19, 2006 5:36 am Post subject: |
|
|
wow I can't believe I just read all 12 pages of this thread ... After that I feel obligated to post. 
Now I'd like to state right off the bat that I'm a newb when it comes to various stage installs that gentoo offers but this is basically what I took away from this thread.
1) Stage1 installs are not officially supported by devs but they are still available for people with "strange" architectures or people who wish to set their USE and compiler flags early on.
2) anything that can be accomplished with a stage1 tarball can also be accomplished with a stage3 but different procedures must be used to obtain the same end result.
3) To obtain a current toolchain/world for a stage3 install requires that you rebuild the system twice (emerge -e system) while a stage1 will only recompile the toolchain once?? (correct me if I'm wrong)
4) bootstrap.sh is considered deprecated or broken and a successful bootstrap may laregely depend on whether the ebuild for python (and somethingelse) is broken when you are trying to build the system.
5) Procedures for a stage 1 on top of a stage 3 are not outlined in the handbook and must be looked up on the forums.
6) Portage currently cannot make a determination whether or not the toolchain is broken.
It seems to me that installing from stage1 will reduce your compile time a little but won't give a very usable system right off the bat like a stage3 will but you don't have to recompile the system and world pkgs twice with stage1. Some people may prefer speed/usability and vice versa. I personally prefer stage1 because that's all I've ever known and I don't need a manual (usually) when I use this method. I can see if it is too much of a hassle to maintain 3 different stages of installation methods for different architechtures but wouldn't it be easier to maintain a standard stage1 install method than a whole bunch of different arch stage3 methods? I would think having one generic standardized stage1 install method available and then watching it closely to find out when it breaks would be easier than maintaining the many stage3 tarballs available...
just some thoughts... I wanted to try to sum up the post the best I could in case people don't read all the pages. I'm still not sure why I read them all
_________________
お前の常識知ったこっちゃねえ！ |
|
| Back to top |
|
|
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 19, 2006 5:51 am Post subject: |
|
|
| Master_d wrote: | | It seems to me that installing from stage1 will reduce your compile time a little but won't give a very usable system right off the bat like a stage3 will but you don't have to recompile the system and world pkgs twice with stage1 |
It won't reduce your compile time a little bit, it will split it in half in the current circumstances. I posted a link to specific test results above...
If the stage3 tarball you are using was built with a recent portage snapshot and you don't need to change any USE flags that effect the toolchain, it would be foolish to go the stage1 route. The only problem is that official release stage tarballs get "stale" after a matter of weeks. Particularly if toolchain updates have happened in the interim... Hell, doing an update on the current stage3 tarball upgrades gcc twice - once from 3.3.5-x to 3.3.6, the second time to 3.4.4-r1. |
|
| Back to top |
|
|
simon_irl
Guru
Joined: 07 Oct 2004
Posts: 403
Location: New Zealand
|
| Posted: Thu Jan 19, 2006 6:10 am Post subject: |
|
|
i no longer particularly care about any of this. the truth of irondog's point
| Quote: | | Stage1 installations make your computer unusable for a whole day => the so-called optimations will never give you back that wasted time. |
has finally hit home with me. i've spent way too many months trying to get my head around esoteric shite that i shouldn't need to know about, in order to save myself (maybe, in a lifetime) a couple of hours of sitting quietly waiting for my computer to do stuff. i won't deny it...i have enjoyed my time as a gentoo fanboy...but now i'm looking for a local chapter of rice-aholics anonymous, so i have a support network in place if i ever again feel tempted to waste precious time trying to inflate my epenis with cflags. |
|
| Back to top |
|
|
amne
Bodhisattva
Joined: 17 Nov 2002
Posts: 6378
Location: Graz / EU
|
| Posted: Thu Jan 19, 2006 9:40 am Post subject: |
|
|
| Bad Penguin wrote: | | For grins I ran a couple of tests. I wouldn't piss on a stage3 install if it was on fire They deprecated the wrong installation method. |
Your tests don't say anything about the extra work Gentoo devs have by supporting three installation methods instead of one, especially considering that much more can go wrong with stage 1.
| Bad Penguin's build test wrote: | | The Gentoo Handbook does not mention that a gcc migration is required, nor is there a link on the documentation pages to the gcc migration guide. There are no specific instructions on how to proceed when you have changed USE flags that require the system to be completely rebuilt while simultaneously there is a gcc upgrade in portage. The author experienced an undocumented feature that automatically switched him over to a new binary incompatible gcc during a previous emerge -Du world, in spite of what the published documentation stated. For this reason it is assumed that the new user magically discern the need for the gcc upgrade, divine the location of the migration guide, and correctly follow the "safe" migration procedures. |
So, did you submit a bug report about it?
_________________
Dinosaur week! (Ok, this thread is so last week) |
|
| Back to top |
|
|
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 19, 2006 3:19 pm Post subject: |
|
|
| amne wrote: | | Your tests don't say anything about the extra work Gentoo devs have by supporting three installation methods instead of one, especially considering that much more can go wrong with stage 1. |
I could have sworn I already replied to this, hmm...
If you can't come up with a stable, consistent method to bootstrap the base system (as in set of "system" packages) or maintain the toolchain, you have much more serious problems than "supporting" 3 installation methods. Regardless, last time I looked at it catalyst uses the exact same bootstrap.sh to build stage2. Not like it would a complete waste of time to fix bugs in it. And I would like to know where you come up with the argument that "much more can go wrong" with a stage 1. In my experience much more goes wrong with a fresh stage3 install, some of which is documented in my build testing. Talk about an urban legend. This assertion is pure fantasy, unless you never stray from the default USE flags already present in the "official" stage3 make.conf. You might as well be running a GRP install.
| amne wrote: | | Bad Penguin's build test wrote: | | The Gentoo Handbook does not mention that a gcc migration is required, nor is there a link on the documentation pages to the gcc migration guide. There are no specific instructions on how to proceed when you have changed USE flags that require the system to be completely rebuilt while simultaneously there is a gcc upgrade in portage. The author experienced an undocumented feature that automatically switched him over to a new binary incompatible gcc during a previous emerge -Du world, in spite of what the published documentation stated. For this reason it is assumed that the new user magically discern the need for the gcc upgrade, divine the location of the migration guide, and correctly follow the "safe" migration procedures. |
So, did you submit a bug report about it? |
No, but I will... |
|
| Back to top |
|
|
amne
Bodhisattva
Joined: 17 Nov 2002
Posts: 6378
Location: Graz / EU
|
| Posted: Thu Jan 19, 2006 4:05 pm Post subject: |
|
|
So basically you rant about things you think you can do better than the Gentoo devs, but don't even file a bug report. There's a reason why stage 1 was dropped, if you want to overcome the problems you see with stage 3 (which are a lot less trouble than supporting stage 1 installs) you're welcome to help with this issues instead of spreading your theories here.
_________________
Dinosaur week! (Ok, this thread is so last week) |
|
| Back to top |
|
|
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 19, 2006 4:07 pm Post subject: |
|
|
| amne wrote: | | Bad Penguin's build test wrote: | | The Gentoo Handbook does not mention that a gcc migration is required, nor is there a link on the documentation pages to the gcc migration guide. There are no specific instructions on how to proceed when you have changed USE flags that require the system to be completely rebuilt while simultaneously there is a gcc upgrade in portage. The author experienced an undocumented feature that automatically switched him over to a new binary incompatible gcc during a previous emerge -Du world, in spite of what the published documentation stated. For this reason it is assumed that the new user magically discern the need for the gcc upgrade, divine the location of the migration guide, and correctly follow the "safe" migration procedures. |
So, did you submit a bug report about it? |
Actually, no, I am not going to submit a bug report because I can already see where it is going, and can't really come up with a better alternative other than ditching the stage3 installation method altogether.
If a user alters USE flags during a fresh stage3 install, then they follow the link about USE flags, scroll down, see the "Adapting your Entire System to New USE Flags", and follow the instructions that tells them to emerge --update --deep --newuse world, you are opening a big fat can of worms. Worms with frickin laser beams on their heads. The kernel is not installed/configured yet, the update would inevitably end up requiring a package that needs an installed/configured kernel, and so on. Chicken before egg. Adapting to the new USE flags will pull in toolchain updates. The automatic switching to the new gcc has apparently been fixed, so everything might build without much of a problem. Do you then tell the user they need to migrate to the new gcc or not, which would require a complete rebuild again? At what point does the most recent stable version of gcc become the default one that is "supported"? Do you let them complete their 30 hour compile of kde and then spring it on them that they need to do it all over with the new gcc, or tell them to upgrade gcc first, so it won't be necessary later to recompile it yet again? All quandries that are avoided by a functioning stage1 install...
The documentation is probably better off like it is now. Don't even point out to the user that they can migrate to gcc 3.4.4 since 3.3.6 will be built by the upgrade and remain the default anyhow. If a newer (binary incompatible) gcc is going to be required by the next 2006.x profile, along with nptl, it is going to get fun around here...
How anyone can support a source based distribution with this installation method and not go totally insane is beyond me. |
|
| Back to top |
|
|
warrens
Apprentice
Joined: 04 Jan 2005
Posts: 239
Location: Don't Tread On Me!
|
| Posted: Thu Jan 19, 2006 4:16 pm Post subject: |
|
|
Stage 3 installs are great if you install Gentoo and DO NOT change CFLAGS, CXXFLAGS, CHOST, use ACCEPT_KEYWORDS="~your arch here", or have nptl or nptlonly in your USE flags. In other words, a standard vanilla Gentoo install. Doing a standard vanilla Gentoo install with anything other than a Stage 3 is a WASTE OF TIME! If on the other hand you change CFLAGS, CXXFLAGS, CHOST, useACCEPT_KEYWORDS="~your arch here", or place nptl or nptlonly in your USE flags while doing a Stage 3 by the Handbook you could very well end up with a broken system, I have.
To do any of the above options you need something better to build your system with. You could start with a Stage 3, rebuild the tool chain, and then do emerge -e system twice (BobP's Stage 1/3 install, in a nutshell), But, this take a VERY LONG TIME to do!! The shortest option for these options is to a Stage 1 install, but you have to watch out for circular deps, and bootstrap.sh filters out the nptl/nptlonly USE flags. So, in my opinion bootstrap.sh is broken and should be fixed, not deprecated!!
To get pass these problems I wrote the "Fiorland Stage 1 Install Guide". I now have a fast and stable system that tooks less time than a Stage 1/3, and just slightly longer than a standard Stage 1 to build. Bad Penguin has writen a drop-in replacement for bootsrap.sh that looks like it should work ( I have not tried it, so I can't say for sure). There are other install options in the forums that I did not mention here to build a system with the before mentioned options.
In my opinion Stage 1 should not be deprecated, but rather fixed. True, it would have taken a lot of work to fix it. Deprecating Stage 1 seems to be the easiest solution for the developers, but the easiest solution is not always the BEST solution.
_________________
The BIGGER the GOVERNMENT, the smaller the citizen.
DON'T TREAD ON ME!!!
My Bias #1
The best government is the government that governs least. |
|
| Back to top |
|
|
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 19, 2006 4:38 pm Post subject: |
|
|
| warrens wrote: | | In my opinion Stage 1 should not be deprecated, but rather fixed. True, it would have taken a lot of work to fix it. |
Amen.
| warrens wrote: | | Deprecating Stage 1 seems to be the easiest solution for the developers, but the easiest solution is not always the BEST solution. |
In actual practice, it appears to be the worst solution for developers. |
|
| Back to top |
|
|
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 19, 2006 5:13 pm Post subject: |
|
|
| amne wrote: | | So basically you rant about things you think you can do better than the Gentoo devs, but don't even file a bug report. |
Hey, it wasn't me that dropped the support. It was apparently decided by what, two or three developers at the most? Mere users were not consulted, asked, or warned.
| amne wrote: | | There's a reason why stage 1 was dropped, if you want to overcome the problems you see with stage 3 (which are a lot less trouble than supporting stage 1 installs) you're welcome to help with this issues instead of spreading your theories here. |
I want to know exactly how it is "a lot less trouble" supporting a stage3 install. I can't seem to locate any facts that support that utter fantasy. At least I offer a manner to test and provide evidence supporting what I am stating here. The results of which fly completely in the face of the "reasons" for dropping stage1 support (it takes longer, it is a waste of time, it is too complicated, there is no advantage to it, blah blah).
I also would like to be provided with a link where an official explanation exists that covers the specific reasons for dropping the stage1/bootstrapping installation method. Something other than "they just want to increase the size of their ePenis".
I have attempted to help. I have filed various bug reports, the responses invariably resemble statements like "stage1 is deprecated", "catalyst is not designed to do that and never will be", "there is no advantage to using stage1", yadda yadda yadda. I bugged the crap out of the catalyst mailing list, they are in the middle of trying to get out a release, they are overworked, etc... All very valid reasons to not pester them.
I plainly stated above that I don't have an immediate better answer. The decisions have already been made and there is apparently not a whole hell of a lot users can do about it other than accept them as gospel. My suggested patches for bootstrap.sh have been rejected because the decision has already been handed down.
The only realistic practical solution would be to come up with an installation and maintenance process that addresses a few relevant shortcomings of portage itself. I have lots of ideas on how to do that, just wouldn't know how to either implement them or wade through the politics around here to get it discussed. With the reception that people get complaining about stage1 going away, I hesitate to bother getting any further involved.
Last but not least, I could be completely wrong. Have been before, probably will be in the future. I can accept that. If someone gives me intelligent debate instead of making vague statements that are obviously not true, I am perfectly willing to be cured of ignorance. |
|
| Back to top |
|
|
warrens
Apprentice
Joined: 04 Jan 2005
Posts: 239
Location: Don't Tread On Me!
|
| Posted: Thu Jan 19, 2006 5:31 pm Post subject: |
|
|
| Bad Penguin wrote: | | Regardless, last time I looked at it catalyst uses the exact same bootstrap.sh to build stage2. Not like it would a complete waste of time to fix bugs in it. |
If catalyst uses bootstrap.sh to build Stage2, which is then used to build Stage3, then fixing the bugs would benifit ALL. Imagine, a better quality Stage 3 for the Stage 3 crowd, and a less problematic Stage 1 for the rest of us!! Sadly though, it does not look like this is going to happen anytime soon. 
If I only had advanced bash scripting skills, then I would rewrite bootstrap.sh myself.
_________________
The BIGGER the GOVERNMENT, the smaller the citizen.
DON'T TREAD ON ME!!!
My Bias #1
The best government is the government that governs least. |
|
| Back to top |
|
|
amne
Bodhisattva
Joined: 17 Nov 2002
Posts: 6378
Location: Graz / EU
|
| Posted: Thu Jan 19, 2006 5:57 pm Post subject: |
|
|
| Bad Penguin wrote: |
Hey, it wasn't me that dropped the support. It was apparently decided by what, two or three developers at the most? Mere users were not consulted, asked, or warned.
|
It was (mostly) decided by the people responsible for the stages, which is good as it's their work area.
| Bad Penguin wrote: |
I want to know exactly how it is "a lot less trouble" supporting a stage3 install. I can't seem to locate any facts that support that utter fantasy. |
More bug reports and support requests due to more things breaking when doing stage 1 -> 2 -> 3 than already starting with stage 3.
| Bad Penguin wrote: | | I have attempted to help. I have filed various bug reports, the responses invariably resemble statements like "stage1 is deprecated", "catalyst is not designed to do that and never will be", "there is no advantage to using stage1", yadda yadda yadda. I bugged the crap out of the catalyst mailing list, they are in the middle of trying to get out a release, they are overworked, etc... All very valid reasons to not pester them. |
As i said, more bugs for the releng team. Now they can finally close them with "stage1 is deprecated" instead of spending their valued time with them.
As for the problems mentioned with stage3, i really don't get it. It works immedeately after unpacking. As far CFLAGS are concerned stage 3 is already compiled with good CFLAGS, if you want your whole system compiled with different ones, no one keeps you from doing emerge -e world (even if its use is doubtful).
I also fail to understand why changing USE flags with a stage 3 should be a big problem, very few things in there are in it because of the USE-flags and if you really want it you can still get rid of them once your installation is finished.
_________________
Dinosaur week! (Ok, this thread is so last week) |
|
| Back to top |
|
|
warrens
Apprentice
Joined: 04 Jan 2005
Posts: 239
Location: Don't Tread On Me!
|
| Posted: Thu Jan 19, 2006 6:26 pm Post subject: |
|
|
| amne wrote: | | I also fail to understand why changing USE flags with a stage 3 should be a big problem, very few things in there are in it because of the USE-flags and if you really want it you can still get rid of them once your installation is finished. |
The nptl/nptlonly USE flags are a problem with a Stage 3 install. To enable nptl you have to recompile glibc. Glibc is 1 of 4 major tool chain packages (binutils, gcc, and linux-headers being the other 3). If you change anyone of these 4 major packages you have to recompile the entire tool chain first and then emerge -e system twice followed by emerge -e world twice. This take a VERY LONG TIME, even on a fast machine. Nptl is one of the best perfomance enhancements that you can make and still have a stable system. Until nptl is enabled on Stage 3 installs it will remain a PITA to setup from Stage 3 
Also, if bootstrap.sh was fixed even the Stage 3 tarballs would be of a better quality.
_________________
The BIGGER the GOVERNMENT, the smaller the citizen.
DON'T TREAD ON ME!!!
My Bias #1
The best government is the government that governs least. |
|
| Back to top |
|
|
amne
Bodhisattva
Joined: 17 Nov 2002
Posts: 6378
Location: Graz / EU
|
| Posted: Thu Jan 19, 2006 7:03 pm Post subject: |
|
|
This is the first time i hear it's necessary to recompile the whole toolchain when turning on nptl (which may be correct). I switched over at least 4 systems to nptl and i never did more then adding it to the USE variable and recompiling glibc (or waiting for the next update of glibc). But even if so, you can recompile your toolchain while your stage 3 installed system is fully operational (meaning you can already work with it) and if problems occur it's easier to support than users that are stuck somewhere between stage 1 and 3.
As for recompiling the whole system is necessary when turning on nptl, this is definitely not necessary.
_________________
Dinosaur week! (Ok, this thread is so last week) |
|
| Back to top |
|
|
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 19, 2006 7:32 pm Post subject: |
|
|
| amne wrote: | | Bad Penguin wrote: |
Hey, it wasn't me that dropped the support. It was apparently decided by what, two or three developers at the most? Mere users were not consulted, asked, or warned.
|
It was (mostly) decided by the people responsible for the stages, which is good as it's their work area. |
Like I said, two or three developers.
| amne wrote: | | Bad Penguin wrote: |
I want to know exactly how it is "a lot less trouble" supporting a stage3 install. I can't seem to locate any facts that support that utter fantasy. |
More bug reports and support requests due to more things breaking when doing stage 1 -> 2 -> 3 than already starting with stage 3. |
How did you determine this? What search terms did you use in bugzilla to come to this conclusion?
| amne wrote: | As for the problems mentioned with stage3, i really don't get it. It works immedeately after unpacking. As far CFLAGS are concerned stage 3 is already compiled with good CFLAGS, if you want your whole system compiled with different ones, no one keeps you from doing emerge -e world (even if its use is doubtful).
I also fail to understand why changing USE flags with a stage 3 should be a big problem, very few things in there are in it because of the USE-flags and if you really want it you can still get rid of them once your installation is finished. |
Yes, it works immediately after unpacking. Then when you want to actually USE the system and start installing a few incidental items (syslog, cron, fstools, kernel, etc...) the fun really starts. Or do you know of a way to boot a stage3 tarball with no portage or kernel? |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Thu Jan 19, 2006 8:03 pm Post subject: |
|
|
i have been ignoring this thread and not even reading it, as i had given up on it a long time ago. i had always thought that everything that had been worth saying had been said at least once or twice, but morbid curiosity got the better of me today. having seen Jorge's comments I thought i'd respond to them.
| jmbsvicetto wrote: | | ...About the Stage1 vs Stage3, I personally like Bob Predaina's Stage1/3 method and think that it addresses some of the issues you raise. Bob has gone as far as creating the Jackass! and Rockhopper! projects which help saving a lot of time for those wishing to start with an optimized stage tarball. From your posts, I gather that you're particularly interested in servers. Perhaps you and anyone else in your position, could help Bob creating optimized stage tarballs for servers that support NPTL and remove PAM and NLS if that's what you like. |
I've never thought that the Stage 1/3 project, the Jackass! Project, or Rockhopper! would be all things for all people, so it really doesn't bother me if some people don't want to use them. I appreciate the kind words from people who like my projects, and I really appreciate the assistance from people who are starting to help out in the support threads. Even though a few of us think that these toolkits are the greatest thing since sliced bread, I don't think that they're a universal solution for everyone. Some people aren't happy with them for whatever reason, and it seems somewhat of a wasted effort for us to try to talk some people who are clearly square pegs into trying to fit into round holes by asking them to use Stage 3 tarballs. when people are clearly insistent on being resistant, maybe we are the people who need to take a hint.
For the record, the whole +NPTL -PAM issue isn't an issue, and it doesn't take -- as some people have alleged -- a Zen Master who's been using Gentoo for years to solve the problem. I am not an IT professional and I have been using Linux for a little over a year. That's all. I have no experience beyond that of the average Gentoo user. I'm just a one-year-old who pays attention and posts a lot of messages.
The people who seem to be making noise about this supposedly have years of IT experience. Making the representation that years of experience with Gentoo are necessary to get Gentoo to do that job properly seems to suggest that someone is missing out on something really basic -- like how to search for solutions. I don't know, but it just seems to me that something is wrong here -- maybe its because years of IT experience doesn't amount to much for some people. Maybe its because this whole topic amounts to nothing more than disinformation and/or a smear campaign by a someone who's more interested in being heard complaining than being a contributor to Gentoo. Maybe somebody who's a really smart IT guy is just milking this job, and making his boss (who reads the forums) think that its exceptionally difficult to solve the problem so that he can make the job last for a few months. Of course, maybe its something else that I just haven't considered, but it still makes no sense to me. Maybe I just don't get it because I'm just the dull knife in the drawer.
The -PAM +NPTL problem was so easy to solve that I would be embarassed to insist on perpetually making complaints about it. When this topic first cropped up, I didn't know how to address the problem. So I googled for "Gentoo PAM removal" and found a very simple Wiki article. I took a Jackass! Stage 3 tarball, untarred it, and followed the Wiki directions. I wrote a big one liner that followed the steps in the wiki, and then i rebuilt the system with a pair of emerge -e systems. finally, i tarred up a new Stage 3 tarball. the whole process from googling for the information to completing the command line instructions took no more than 5 minutes of seat time.
so i built the tarball, and for at least a month its been sitting on the Jackass! Testers FTP server waiting for someone to download it. Nobody cared enough to inquire -- not even those IT people who have wasted over a month of an employees time trying to duplicate the 5-minute effort.
i think that there are a couple of take-home points to be considered from this:
1. some people just like to complain
2. -PAM +NPTL is a simple problem with a simple solution. theoretically speaking, simply reading the Wiki article like I did is enough to give the casual user all of the information that he needs to solve the problem. i did it in 5 minutes. you don't have to be a Zen Master to know this stuff. a simple search for the right terms is all that's required.
3. practically speaking, its a simple solution to physically create the media necessary to introduce this product into a production environment. i spent 5 minutes of seat-time reading the Wiki article and writing a one-line command to build the system. it took 2 hours of mahine time to perform the redundant system build on my old 2.4 GHz P4. a nice Stage 3 tarball was the result. this Tarball could easily be used to replicate a -PAM +NPTL installation across any array x86 servers with minimal effort. personally, if i were doing it, i'd install once and then replicate disk images.
4. you can lead a horse to water, but you can't make him drink.
5. this whole -PAM +NPTL thing seems to be a dead issue that just refuses to stay dead. by not ignoring it, we serve those whose goal is to keep it alive and kicking.
regarding help with Jackass! and Rockhopper!, i'd certainly love to have help from people who are willing to help. but i don't need any help in building a -PAM +NPTL Stage 3 tarball for replication on a server environment -- i already knocked that job off in 5 minutes of seat time just to prove my point. since its already been published in the wiki, i think that everyone reading this thread should be able to do it just like i did. the interesting thing to me is that this continues to be perceived as a problem -- somebody just doesn't want to use the solution, and it appears that their employer is paying an employee to waste an awful lot of time -- maybe the employee is just trying to make the problem last as long as he can, so his boss thinks that he's working while he's actually screwing off at work.
for the record, i'm deleting the -PAM +NPTL system from the Jackass! server. i had thought that a professional web hosting service that had been wasting countless man-hours paying an employee to attempt to solve such a problem would have gladly paid for a quick turnkey solution to the problem, but that didn't happen. since the tarball is just wasting space on my hard drives now, away it goes.
what really amazes me is that a professional IT house would consider NOT using a straightforward, pre-built solution to the problem, and that they would prefer to be left spinning their wheels for so many weeks. ultimately time is money, and they'd be money ahead to use something that works instead of spending weeks or months squirming about a problem they still haven't solved.
no, i'm not interested in working on or maintaining any sort of -PAM +NPTL project for servers. IMHO that is not a community endeavor -- that's a unique system that's needed by professional data houses. its a simple enough problem to solve, and ultimately, its the responsibility of professional data houses to employ competent people who can rapidly address their problems.
edit: corrected spelling of Jorge's name 
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Last edited by Bob P on Fri Jan 20, 2006 2:54 am; edited 1 time in total |
|
| Back to top |
|
|
Bad Penguin
Guru
Joined: 18 Aug 2004
Posts: 507
|
| Posted: Thu Jan 19, 2006 9:05 pm Post subject: |
|
|
| warrens wrote: | | If I only had advanced bash scripting skills, then I would rewrite bootstrap.sh myself. |
Here is a simple 22 line patch to the bootstrap script. It fixes the STAGE1_USE bug that throws out all of the supported stage1 USE flags and exits after the first gcc upgrade so you can verify gcc-config.
So instead of jumping through weird hoops and using alternative installation methods found in the forums, all you have to do is add whatever use flags you want in make.conf, bootstrap.sh, emerge -e system.
| Code: |
--- bootstrap.sh.orig 2006-01-15 13:57:21.000000000 -0600
+++ bootstrap.sh 2006-01-15 14:03:38.000000000 -0600
@@ -27,7 +27,7 @@
show_status() {
local num=$1
shift
- echo " [[ ($num/3) $* ]]"
+ echo " [[ ($num/5) $* ]]"
}
# Track progress of the bootstrap process to allow for
@@ -92,7 +92,7 @@
RESUME=0
if [[ -n ${STRAP_RUN} ]] ; then
- if [ ${BOOTSTRAP_STAGE} -ge 3 ] ; then
+ if [ ${BOOTSTRAP_STAGE} -ge 5 ] ; then
echo
einfo "System has been bootstrapped already!"
einfo "If you re-bootstrap the system, you must complete the entire bootstrap process"
@@ -273,7 +273,7 @@
export ENV_EXPORTS="GENTOO_MIRRORS PORTDIR DISTDIR PKGDIR PORTAGE_TMPDIR
CFLAGS CHOST CXXFLAGS MAKEOPTS ACCEPT_KEYWORDS PROXY HTTP_PROXY
- FTP_PROXY FEATURES STAGE1_USE"
+ FTP_PROXY FEATURES"
eval $(python -c'import portage,os,string;print "\n".join(["export %s=\"%s\";[[ -z \"%s\" ]] || einfo %s=\"%s\";" % (k, portage.settings[k], portage.settings[k], k, portage.settings[k]) for k in os.getenv("ENV_EXPORTS").split()])')
unset ENV_EXPORTS
@@ -304,8 +304,8 @@
# We can't unmerge headers which may or may not exist yet. If your
# trying to use nptl, it may be needed to flush out any old headers
# before fully bootstrapping.
-if [ ${BOOTSTRAP_STAGE} -le 2 ] ; then
- show_status 3 Emerging packages
+if [ ${BOOTSTRAP_STAGE} -le 3 ] ; then
+ show_status 3 Emerging packages pass 1
if [[ ${RESUME} -eq 1 ]] ; then
STRAP_EMERGE_OPTS="${STRAP_EMERGE_OPTS} --resume"
cp /var/run/bootstrap-mtimedb /var/cache/edb
@@ -316,9 +316,24 @@
:
fi
${V_ECHO} emerge ${STRAP_EMERGE_OPTS} ${myOS_HEADERS} ${myTEXINFO} ${myGETTEXT} ${myBINUTILS} \
- ${myGCC} ${myLIBC} ${myBASELAYOUT} ${myZLIB} || cleanup 1
+ ${myGCC} || cleanup 1
echo -------------------------------------------------------------------------------
- set_bootstrap_stage 3
+ set_bootstrap_stage 4
+ if [[ -n ${STRAP_RUN} ]]; then
+ einfo
+ einfo "Run gcc-config and select your desired version of gcc before continuing."
+ einfo "After setting the gcc version, re-run bootstrap.sh to finish the bootstrap."
+ einfo
+ exit 0
+ fi
+fi
+
+if [ ${BOOTSTRAP_STAGE} -le 4 ] ; then
+ show_status 4 Emerging remaining packages
+ ${V_ECHO} emerge ${STRAP_EMERGE_OPTS} \
+ ${myLIBC} ${myBASELAYOUT} ${myZLIB} || cleanup 1
+ echo -------------------------------------------------------------------------------
+ set_bootstrap_stage 5
fi
# Basic support for gcc multi version/arch scheme ...
|
|
|
| Back to top |
|
|
warrens
Apprentice
Joined: 04 Jan 2005
Posts: 239
Location: Don't Tread On Me!
|
| Posted: Sat Jan 21, 2006 6:48 pm Post subject: |
|
|
My distaste for Stage 3 install comes from personnal experience with Stage 3 installs. I have been using Gentoo for just a little over a year now. My first install, 2004.3, was on my desktop and was from Stage 1, I had no problems getting a working system. It worked so well for me that I decided to install Gentoo on all my systems.
My next system on which I install Gentoo was my laptop. Since my laptop is a slower system than my desktop I decided to go with a Stage 3 install to save some time. Stage 3 did not save me any time, as I ended up with a broken install that would not build anything beyond the kernel. Needless to say that I was not a happy camper. Back to what worked on the desktop, Stage 1. The Stage 1 install worked great once again on the laptop, now 2 systems on Gentoo, one left to go.
By the time I installed Gentoo on my server 2005.0 was released. I thought ok Stage 3 should be fixed by now, so let me try Stage 3 again. Guess what happened next. Yes I had another broken install!! Not just once but twice on this system!!! At this point I decided that I would not do another Stage 3 install on any of my current systems or any future systems, Stage 1 only from then forward. Don't ask what went wrong for me with Stage 3 as I do not remember what went wrong.
So when I first heard that Stage 1 was being deprecated I was PO'ed!!! The Gentoo Release Engineering Team had deprecated the only installation method the worked on my systems, not a good sign.
I tried BobP's Stage 1/3, great guide, my kudos to BobP. Worked great, but took 2 to 3 times longer to build than Stage 1! I thought that there got to be a better way!! Time to look at Linux From Scratch again.
I had built a Linux From Scratch system about 1.5 years ago. It was great after I got it built, only took a month to get a fully working system, way to long!! And upgrading the system was even more painful!!
Anyways, I thought what if I took Gentoo and applied the build style of LFS, what sould happen? So on my testing partition on my desktop I setup the test environment. I took a Stage 1 tarball and extraced it. Then starting with LFS chap. 5 I emerged the packages for the tool chain. I then followed on through the LFS book through chap. 6, after which I did emerge -e system. It worked great!!! This became the genisis of what is now the "Fiorland Stage 1 Install Guide" I worked out the details of Fiordland on my laptop. Fiordland has produced the fastest and most responsive Linux desktop that I have seen thusfar. The build time with Fiordland falls somewhere beteen a standard Stage 1 and BobP's Stage 1/3, however it seems to be closer to the time of a standard Stage 1. If Fioland becomes a popular intall method, that will be just great. If not, it won't bother me in the least as it was mainly created to scratch my own itch.
In my opinion I think that it was a bad idea to deprecate Stage 1 install, but it has been done and there in not much that I can do about it. I do think that fixing bootstrap.sh would benifit ALL Gentoo users, even those that do a standard Stage 3 install. Use whatever installation method that works best for YOU, whether it be a Stage 3 by the Hanbook, Stage 1/3, Fiordland, or other method that is listed in these forums, and most of all, BE HAPPY!!!
_________________
The BIGGER the GOVERNMENT, the smaller the citizen.
DON'T TREAD ON ME!!!
My Bias #1
The best government is the government that governs least. |
|
| Back to top |
|
|
Aman9090
Apprentice
Joined: 04 Nov 2003
Posts: 234
|
| Posted: Mon Feb 06, 2006 12:36 am Post subject: What the hell happened to stage 1 & 2? |
|
|
Maybe I missed something here, but I went ahead and downloaded a stage2 tarball for my AMD64 Gentoo 2005.1 installation. I thought I had forgotten all of those steps required to progress from stage 2 to stage 3, but I then realized that the Gentoo handbook never even makes mention of a stage 1 or stage 2! Where did the instructions for stage 1 and stage 2 installs go, and can anybody please link me to them? I simply cannot remember everything required in the stage 2 installation, and I really don't want to go through all of the work I've gone through already all over again (I've gotten up to the point of kernel compilation!).
Any advice and help would be really appreciated. I am a little confused, to say the least...
Thanks in advance!
-Andrew
EDIT: Okay, I have discovered that Gentoo handbook no longer offers help for the Stage 1/2 installs. However, I did find a little FAQ notice on how to do a stage1/2 install. Does the stage 2 install merely require the emerge -e system step, or must I do the bootstrap as well?
Thanks again! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
