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

Dan McGhee beesnees at grm.net
Sun Oct 6 07:51:27 PDT 2013

On 10/05/2013 11:11 PM, Rob Taylor wrote:
> Hi Dan,
> Thanks for the feedback. I'm just on vacation for a couple of weeks to 
> Hawaii, the big island. So I may not seem very responsive to emails 
> for a bit.
Oh goodness! I don't want to impact your vacation, but I'll still 
post--so that you can respond if you think this stuff is as much fun as 
Hawaii.  :)  BTW. I retired three years ago, so I am on continuous 
vacation.  I love it.  Besides, in one of my previous lives I was an 
engineer, and right now I'm trying to line up all my ducks before I 
start my build. So there is plenty of time.  There are a few things I 
want to play with during my Ch. 5 efforts (see below) and that will slow 
me down.
> Feel free to change or use anything I have created. I didn't really 
> take over the hint, partially because I am not sure how much time I 
> will have to put into supporting it. But I did work on the wrapper 
> scripts because I tried out this user package management idea and I 
> could see room for improvement. Anything you or anyone else can add to 
> improve this project is welcome.
Which goes to my first question in this round.  As a general statement, 
I'm closely reading the build and build.conf scripts. All of my 
questions stem from that.

Where can I find the 'root_{pre,post}_commands'?  They do not appear in 
'build.conf' and don't seem to be defined in 'build.' You call them as 
for .configure, make and install and make the logs, but I can't find the 
commands themselves. Ubuntu uses gedit for it's text editor and, when 
you print the file, it puts things in nice pretty colors depending on 
what the statement is.  The last technicolor statement in the build 
script is "echo -n "Preparing for install(root)...". The next statement 
calls root_pre_install_commands, and it is in black as is the rest of 
the printed script.  I'm thinking that it can't find the commands.

I downloaded the tarball yesterday.
> ...Su no longer exists in coreutils so copying it in section 5 can not 
> occur. I see from the other effort mentioned here 
> https://github.com/ericherman/package-users that he suggests 
> installing shadow into the /tools area instead of /usr. That would 
> make sense to avoid any collision of files later when the normal 
> shadow install occurs.
This is one of the things I thought I'd play with after I learned about 
no 'su.'  My building skills are a little stale, but they're slowly 
coming back.  I seem to remember that you can 'make' or 'make install' 
individual targets.  I'm wondering if you can do that in 'shadow' during 
Ch. 5.  I think--remember I'm stale. please don't laugh--' make 
target=su' or 'make install -su'. If it's possible, the syntax escapes 
me right now.  I seem to remember that there are some packages in LFS 
that build only one or a few targets in a package.  I'll review the 
syntax and see what happens.
> I thought about changing my_lfs_7_4_notes.txt 
> <https://www.javacrypt.com/lfs/my_lfs_7_4_notes.txt> to use that 
> approach but then decided that the example of how to deal with file 
> overwrite issues is a useful demonstration of the scripts handling of 
> these issues.
Gonna re-read those to see if it helps with the 'root_*_install 
commands' stuff.
> 6. The build script will still quit after a section such as the 
> "check" fails. What I was referring to is that rather than a command 
> such as
> install -c -m04755 -o root -g root ../../sourcefilename /sbin
> failing and causing the entire "make install" to fail because the package user does not have permissions to run it,
> my wrapper scripts will filter out the -o root -g root and will alter the -m04755 to be -m755 and will create a log
> of the command as it was before and after modification, present working directory when the command ran, any errors returned from
> the command if it was run and in doing so the "make install" will continue to run through to completion installing any and all
> files that would have been run after the failure. So when you are all done with a successful install, all you need to do is
> examine the logs to see the list of files that you may or may not want to make SetUID or SetGID root etc..
> My wrapper scripts will also examine any issues of ownership of files, log those issues and skip the specfic command that would
> have generated a permission error so that the "make install" will continue as far as possible generating a complete list of these
> files with ownership issues so that a single chown command can be run to fix all these permissions issues before rerunning
> "make install" again without issue. You really would have to experience the process to appreaciate what I mean. Also, suppose you don't
> want this package to have replaced those specific files where there was an overwrite situation? In this case if the overwrites
> (which are logged for reveiew) are the only issue with an install and the install completed with a result of success, you can simply move on.
> This is much more seamless than having to edit "Makefile.in" files removing or fixing offending entries and running
> "make install" over and over again until it finally succeeds. Or moving files you want to "save" so that a "make install" can succeed just
> to have to move those saved files back again as root overwritting the newly installed files with the ones you wanted to keep etc..
> You can always run the build script with a list of phases as options to step through the install at yourown  pace. But then the ./build
> script itself is open to change as well if you like.
This is a great improvement to this system.  Matthias did a great job 
engineering it.  However, as Linux and LFS grew and became more 
sophisticated, the original hint became a little (?) pedantic and "brute 
force." After a couple of builds, the interruptions were more than 
merely frustrating.  That's why after I built my first {,B}LFS system, I 
generated my own install.dir.lst.  I really want to see those 
'root_*_install commands."
> Thanks again for your feedback, I hope I didn't miss addressing any of your points.
Thanks for your efforts.  You got them all. But.......I have some new 
ones. :)

I've beaten the "root_*" stuff enough.  In addition, however, I didn't 
know that you could "su" in a script.  That makes things really great!

I'm gonna go back to your build notes because I don't want to ask a dumb 
question about build directories.  However, since you use 'ln -s' are 
the xxxbuild and yyysrc directories just "dummies" or do they actually 
exist? If they exist, what is their purpose?

Last thing so you can continue to vacation.  I was interested to see how 
you handled all the tar.{xz,gz,bz.bz2} files.  PATTERNS seems to be the 
key.  In build.conf "PATTERNS='4.3.2.tar". I don't understand this.  
Would you explain it?  I hope this isn't going to be a "duh moment" for 
me. :)

Thanks for getting back to me.  Enjoy the sun and fun.  In another venue 
I'll tell you about the "Kalakua Death March" I learned in the Navy.

You take care too,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20131006/fb3238b2/attachment.html>

More information about the lfs-support mailing list