[lfs-support] More control and package management using package users

Dan McGhee beesnees at grm.net
Tue Oct 8 07:16:19 PDT 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20131008/5d557b89/attachment.html>


More information about the lfs-support mailing list