On Wed, 11 Nov 2020 09:26:29 -0500 Jean-Marc Pigeon <j...@safe.ca> wrote:
> Hello Scott, > > On Wed, 2020-11-11 at 09:02 -0500, Scott Andrews via blfs-support > wrote: > > [....] > > have a system I can boot my raspberry pi from and ssh into straight > > away. It is a complete "base" headless system. I then add what ever > > that particular system needs for its function. I can replaicate > > this as many times as needed and it is completely stable. > > > > [rant] > > What I have learned from LFS is how to fix issues that LFS > > refuses to fix, and also the building sequence for a core > > system, nothing else. What is really learned from cutting > > and pasting from a book? > > > > You don't really learn until you do use a package manager > > and then you see all the "liberties" that LFS has taken with their > > process that causes all kind of grief for the package > > builder and maintainer. Notice NO ONE (other than individuals) > > builds a system WITHOUT a package manager. > > > > That is insane and why package managers were invented. With > > a package manager you know exactly the dependencies for each and > > every package and you can completely control those. > > Building without a package manager generally results in a chaotic > > system. > > > > BTW it looks like no one here knows of the concept of > > building packages in a clean chroot. Let alone the benefits from > > doing so. > > [/rant] > > The LFS purpose is to demonstrate how to build a "linux system from > scratch" (Period). All you need to know is how to build a tool chain, the rest is easy. LFS doesn't do even a good job at demonstrating how to build a linux system from scratch. It shows you their way only and doesn't explain how the system V init works, or how anything else works for that manner. It is simply a script, ie build sequence which is poorly explained. It is not even generic and they don't want it to be, so if you fit that narrow definition then I guess it works for you. Question: What do you have when you have completed your build? Not much different that installing arch linux or any other distro. If you really want to learn read the arch wiki and USE FreeBSD. then you will really learn operating systems and package building. LFS can't and won't give you a kernel config file that works as a starting point. So if I spend two weeks cut and pasting from the boot and can't get the kernel to boot because I can't get it configured at all, just what is I really learn? All you see is a core dump. Their should be a default kernel config that will at least boot the mess you have just created. It may be very primitive but at least your work can boot. Then you have a starting point to learn how to configure the kernel for your system. When working with the ARM folks you have a kernel that will boot so you can bend, break it and learn. Not look at a screen that tells you nothing and doesn't boot. That ain't learning, that is turning people away as they have spent a large amount of time and end up with nothing usable. Look at the raspberry pi foundation.... That is how you involve and teach people. > Mainly to make sure the components are buildin the "right" order > (trying to avoid > dependecies loop, which not an easy task). LFS doesn't even show you all the dependencies and doesn't have any tools to determine that. Doesn't teach anything about the tool chain other then their method. LFS teaches cut and paste, not much more. Buildroot is another process one can use and it is more complete. It has more support while it is my opinion that LFS is losing support. That is based on the posting to here, much less that years ago. I have monitored the mail here since before LFS-5.0. https://en.wikipedia.org/wiki/Buildroot > > I am using RPM+zypper to build/manage my "own" distribution (see my > signature). > it wouldn't be achieved without LFS and I am still using LFS when > my RPM can't compile anymore because some low level component API was > changed by upstream without consideration. I never had an issue with that and I have been using rpm since about 1995. I have posted to their mail lists concerning many issues and they are always responsive, even to the point of showing you work a rounds to your issue. I have never experienced that on LFS mail lists. > > LFS team is doing a great job, trying to keep all components up to > date AND in working order... > Once again it is not a pre-cooked distribution it is a leaning tools, > as such you are entitled to > adjust you setup according your needs and taste (once you reach the > confidence level about building it) It should be a working distribution...... > > As learning tools, If I could suggest something to the LFS team, > its about discarded components, my advices is to keep them within the > LFS tree > with a RED-TAG explaining why (and when) it was discarded. Discarding > components and knowing why is part of our collective learning process. > > Your dreaming...... My posts here yesterday is about fixing a tool and adhering to standards. Bruce says I am wrong about the LSB standard Here is the standard from LSB-Core-generic about init scripts. Read it for yourself..... Conforming applications may install one or more init scripts. These init scripts must be activated by invoking the install_initd command. Prior to package removal, the changes applied by install_initd must be undone by invoking remove_initd. See Installation and Removal of Init Scripts for more details. install_initd and remove_initd determine actions to take by decoding a specially formatted block of lines in the script. This block shall be delimited by the lines ### BEGIN INIT INFO ### END INIT INFO Notice it states "init scripts must be activated by invoking the install_initd command" LFS doesn't even come close to that as they are manually manufactured. LFS doesn't even have install_initd or remove_initd. More from LSB-Core-generic 22.4 Installation and Removal of Init Scripts Conforming applications may install one or more initialization scripts (or init scripts). An init script shall be installed in /etc/init.d (which may be a symbolic link to another location), by the package installer. During the installer's post-install processing phase the program /usr/lib/lsb/install_initd must be called to activate the init script. Activation consists of arranging for the init script to be called in the correct order on system run-level changes (including system boot and shutdown), based on dependencies supplied in the init script (see Comment Conventions for Init Scripts). The install_initd command should be thought of as a wrapper which hides the implementation details; how any given implementation arranges for the init script to be called at the appropriate time is not specified. Example: if an init script specified "Default-Start: 3 4 5" and "Default-Stop: 0 1 2 6", install_initd might create "start" symbolic links with names starting with 'S' in /etc/rc3.d, /etc/rc4.d and /etc/rc5.d and "stop" symbolic links with names starting with 'K' in /etc/rc0.d, /etc/rc1.d, /etc/rc2.d and /etc/rc6.d. Such a scheme would be similar to the System V Init mechanism, but is by no means the only way this specification could be implemented. The install_initd command takes a single argument, the full pathname of the installed init script. The init script must already be installed in /etc/init.d. The install_initd command will not copy it there, only activate it once it has been installed. For example: /usr/lib/lsb/install_initd /etc/init.d/example.com-coffeed The install_initd command shall return an exit status of zero if the init-script activation was successful or if the init script was already activated. If the dependencies in the init script (see Comment Conventions for Init Scripts) cannot be met, an exit status of one shall be returned and the init script shall not be activated. When a software package is removed, /usr/lib/lsb/remove_initd must be called to deactivate the init script. This must occur before the init script itself is removed, as the dependency information in the script may be required for successful completion. Thus the installer's pre-remove processing phase must call remove_initd, and pass the full path name of the installed init script. The package installer is still responsible for removing the init script. For example: /usr/lib/lsb/remove_initd /etc/init.d/example.com-coffeed The remove_initd program shall return an exit status of zero if the init script has been successfully deactivated or if the init script is not activated. If another init script which depends on a boot facility provided by this init script is activated, an exit status of one shall be returned and the init script shall remain activated. The installer must fail on such an exit code so it does not subsequently remove the init script. Note: This specification does not describe a mechanism for the system administrator to © 2015 Linux Foundation 855 22 System Initialization LSB Core - Generic 5.0 manipulate the run levels at which an init script is started or stopped. There is no assurance that modifying the comment block for this purpose will have the desired effect. Now explain to me how LFS is even remotely compliant..... Please leave the reply to set to blfs mailing group -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
