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,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
