I dont know how the blfs book could be just parsed and run. Some seperation tags might be use full. There are so many packages in there that 1) the user isnt going to want 2) needx extra configuration that cant just be automagicly done for the user. example is a fair ammount of us will want the packages installed in different locations then the book. I have been thinking about how this could be done properly and with enough flexability that it will be usefull to alot of people. I would like to get some thoughs and comments about how this needs to be done (pokes Gerard). Here is what I have come up with.
when you install MS office or what ever you have a multi tree area. you select word then from the branches you instal filters and languages etc. then the next tree is excell etc... in my mind somthing similer to nALFS's curses tree would be great for the majority of selecting from the user side. but we will also need to have areas to input text for optimisations and paths. I dont know that we can exactly just pull from the blfs book to get the blfs part done. I would suggest that that be a starting point for the profile snipit for that item. then add in options like the check box for adding --with-mysql or, check box --sysconfdir=[Textbox] This is all user interface thought, how ever I feal it also bares alot on how we handle the Blfs portion of profile/compile work. I dont see any problems with lfs being directly parsed from the book and make a profile hunk for lfs/clfs/hlfs. When you start the program you just select one of those 3 from the base section the UI applys any nessasary "filter/modification" to the blfs begennings and you go through and select things from there. My use of "filter/modification" is for example --enable-pax and other hardened options that you would need enabled. Since in non pax systems the options are not always there, the selection of the hlfs base package would set a mark --enable-pax && enable pax sed commands. The blfs side would now have areas where if pax is aready properly supported a check box for enableing it in the package. If there is a special blfs sed/command for enabling pax ( i think just a fiew packages are like this) it would either get automaticly added to the profile or a new checkbox marked would show up. Now for how the "profile" needs handeling. This is just speculative thought. I could almost see it being handled like CPAN's. There is a list of what packages we already have a build process for from the book's. you either grab them all before hand or posibly live as you go along. If you create a new one you post it to the alfs profile area and it gets looked at and added to the repository. Especialy helpfull for programs that need specific modifications for lfs but may not be popular enough for the book yet. Once the bits of blfs are downloaded you start up your client or if its built in you start checking off what else you want on your system after you mark the lfs base you want it made from. mark off all options that aply for you the system/systems that will be building it then tell the compile systems to get to work. This way the end user shouldent have to edit any profile just chek off options needed for their build. I could see some new tags being used for seperation of commands when trying to use a base other then lfs. the lfs tags would be the default used, if theres a hlfs patch for the package it would use the hlfs tags during a hlfs build. if there were no hlfs tags for the blfs package it would use the default of lfs tags. Thats just my nickle and dime's worth ;) Kendrick Tapio Kelloniemi wrote: >In BLFS, however, we have many such commands, for example commands in sections >"Additional X Window System Configuration" and "X Window System Components" >should never be executed >automatically. > -- http://linuxfromscratch.org/mailman/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
