On Sun, Aug 20, 2006 at 09:48:23PM +0100, Reece Dunn wrote: > > I am interested in the (C/B)LFS project. For a while now, I have wanted to > make the move from Windows to Linux. I have been using cygwin for a long > time now, so am familiar with the Linux command line, and have been using > more and more Linux/opensource software (e.g. Firefox). > > LFS is an ideal distribution for be, because: > * I already know how to use bash, rm, tar and the like from cygwin; > * it gives me the opportunity to discover Linux things gradually (like using > chmod to make scripts executable); Au contraire, any variant of LFS will drop you in at the deep end. It's great for learning how things fit together, but my opinion is still that most people shouldn't come here until they know what they dislike about the distro they are using - if all you want is a spartan system, fine, but for most of us it helps to know which packages we want to use, and trying out the alternatives from a distro is a lot simpler.
At one time, I think Gerard said we should be on the bleeding edge, but since then fedora has sprung up to extract the blood from its victims :) Seriously, playing with new versions is great, and being able to fix the brokenness in them is even better. By the time an LFS book is released, all those problems have hopefully been ironed out. If you are ready, great, enjoy the build. > * the major distributions I have tried either don't support what I want out > of the box (e.g. mp3 support), don't allow the configuration I need (e.g. > have problems with loadkeys gb or loadkeys uk), have problems with my > hardware (e.g. problems with getting the soundcard on my laptop working), > or come with software I'll never use (how many variants of bash do you > need anyway?); At any given time, one version of bash is enough, but preferably a fully working version [ in-joke for readers of clfs-dev :) ]. So far, I haven't seen out-of-the-box mp3 support in any version of LFS - personally, I use mpg321 for mp3 (GPL'd and nominally maintained), but even mpg123 is a matter for BLFS. In that sense, we aren't a distro, you build exactly the (blfs) applications you want and nothing else. > At the moment I have completed chapter 5 of LFS 6.2. After a few > mis-steps in the early stages, I started putting the commands I was running > into shell scripts: one per package/sub-chapter. This then got refactored > into a generic package shell script which has evolved into a C++ project > for automating a build and install of a package. It is still very early in > development, but is building most of chapter 5 (the bootstrapper and > minilfs). It is also building other packages as well. > Just about everybody on -dev uses some form of automation, but that doesn't mean you should automate before you can build it by following the book. Building a c++ program to build and install sounds like severe overkill - the reason shell scripts are so popular is that they are easy to modify and they have enough power for this sort of use. Look at any normal configure file - it's a shell script. Adding a layer of c++ on top of this will no doubt give you excellent bragging rights when you get it working, but it's a distraction from learning how the parts of a linux system fit together, and probably a pain in the proverbial to debug. > My aim is to build all of the boostrap stage and minilfs using my package > manager tool. The aim then is to use this to manage what packages (and > their versions) are installed on my system. The next phase is then to use > my tool to build the LFS system and then go beyond.. :)! > You will also have seen the thread Chris started about people who use package management tools before they're ready for them. Oh well, at worst you get to keep both pieces when it breaks. I'm not saying that package management isn't a good idea. I log my installs - I miss some updated header files, but the minimal process I use works adequately for me, it isn't as if I'm going to uninstall packages after deciding they're no use to me, a fresh install of a system will happen soon enough. The point is to get a working system. Once you know how to do that, by all means explore your own ideas on package management - apart from anything else, doing it in your preferred graphical desktop is usually a lot easier than keeping multiple ttys open while you hack your source code. > One of the problems I have found when using automated scripts is at the > changeover points. That is, when executing 'source ~/.bash_profile' after > the core tools have been build and executing chroot after minilfs has been > built, a new bash prompt is created, stopping the build process! If I don't > execute the 'source ~/.bash_profile' command, the bash in /tools/bin is > trying to look for libncursesw.so.5.5, but the ncurses step only builds > libncurses.so.5.5. > If you automate, you have to know what to change. Looks as if you've started the learning process. For the chroot part, clearly a separate script/program is appropriate. I don't recognise the ncurses probem, and anyway this isn't the place to discuss the minutiae of automated builds (try -chat, but don't expect responses from me, I'm going on holiday in a day or so). > At the moment, I am building LFS on my laptop. Once I get it working, > I'll build it on my desktop. Then, I would like to get (C)LFS working on > a PDA - for that, I'll want to create a 'lean' version of CLFS. > When you look at clfs, look at clfs2 - it's about cross-compiling the whole system, but I'm not up to speed with it (too busy looking at testsuites in clfs1) and again this isn't the right list to discuss it. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
