On 10/07/2013 11:27 PM, Rob Taylor wrote:
Dan,
The build script itself already exists in the
"more_control_helpers.tar.bz2" which is as it was before I got to it.
I altered it a little but for the most part it is as I found it. Now
that is not to say that I can not explain most of what it does... I
can, however I don't want to take credit for its design or function.
Now some things become quite clear for me in the historical sense. After
reading this e-mail, I went to the Change Log in the hint and saw some
things dating back to 2005. I wasn't aware of these. I'm trying to
find the exact date, but my last download of the scripts and helpers
must have been before Matthias' update in Dec, 2005. Whenever I got
ready to build LFS I just skimmed the hint to see if there were any
major changes, but used the one I had originally printed and maintained
my notes. I can't find it now. Drat! I thought you had developed the
build.conf concept, but apparently you didn't. Still. The wrappers you
modified and the helpers you designed, IMO, should be mentioned in the
Change Log. Build.conf is NOT in that log. That's why I thought you
did it and why you should make entries there. Some people do read those
things. :)
Re:root_{pre,post}_install
I noticed that when a function is missing from the build.conf file,
the step is just skipped. It appears that Matthias was experimenting
with this and didn't include it in the build.conf. I haven't tested
it, but the -c switch given to the su command is generally how you can
execute a script or command as a different user. So calling the script
itself with a specific option mentioned, and executing it as an option
to the su command should theoretically execute that phase of the
script as the specified user (in this case root). I expect the build
script would pause at this point expecting the user to enter the root
password since I don't see how it is getting passed.
My conclusion is, then, that they don't exist yet. I'll stop looking.
First reaction: I can't remember if it's a vim or emacs convention, but
my experience is, when working with an executable script in a graphic
text editor, that no color coding indicates a syntax problem and the
script will stop running at that point. Usually it's an extra or
missing 'fi,' a typo or a bracket problem. When I get there, I'll test
this build script to see if it runs. How long has it been since you
used it? (I think there is an extra 'fi' when calling the
root_pre_install commands. But, as you said, if it's not in build.conf
it would skip to _install.)
Second reaction: I'm just gonna have to look in the Advanced Bash
Scripting Guide I have--after I make sure it's current--and check on su
in a script. Regardless of the parameters passed, I think it's a bash
"no-no."
<https://www.javacrypt.com/lfs/dev_user_package_management.txt>
If you look at the source code for the wrapper scripts that I have
been working on, you will see they seem rather involved. I noticed
that there was a great variety of ways that packages used the
commands: install, rm, ln, sln, unlink, mkdir, chmod, chown, chgrp
etc.. I also noticed that they did things that don't even seem to be
documented, such as placing folder and file references first and
options last, or putting the -m option between source and target file
and directory options. Also did you know that it is perfectly
acceptable to have a line feed in the middle of a file name? One of
the packages test this and so my wrapper scripts had to become more
and more robust to deal with these oddities.
But on that note it is worth mentioning that the wrapper scripts are
not really required until the "install" step. If you suspect that a
"make check" or "make test" is failing due to the wrapper scripts you
can simply disable them by changing the path, for the "build check" step.
For example, the rebuild of coreutils to enable "acl" in the BLFS was
checking things that were not permitted by the wrapper scripts... so I
simply did this in the build.conf file for the check function:
check_commands()
{ :
# for whatever reason, the wrapper scripts caused make test to fail
so...
WRAPPER_PATH="$PATH";# back up the PATH
export PATH="/bin:/usr/bin:/sbin:/usr/sbin";
make test
export PATH="$WRAPPER_PATH";# restore the PATH
}
It's for these things I think you should take credit in the Change Log.
That's a lot of work.
I am creating a "my_blfs_7_4_notes.txt" file, to carry on from the
similarly named LFS file, but I am a long ways off from publishing it.
I read your lfs notes and your developer notes. Outstanding job.
I almost have the su thing ready to go. I've got to correct somethings
in my current build and then I'll at least get su in /tools. It will be
a couple of days before I get to Ch. 6 to test it.
Enjoy your vacation and take care,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
