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

Rob Taylor rtaylor777 at gmail.com
Sat Oct 5 21:11:35 PDT 2013

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

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

re: 1 and 5...  I didn't alter the text of the hint itself (supplied on the
I believe that there are lots of changes required now, including
installing shadow before section "6.7. Linux-3.11 API Headers" in order to
get the su command. 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. I
thought about changing
use that approach but then decided that the example of how to deal
file overwrite issues is a useful demonstration of the scripts handling of
these issues.

2. I installed AUFS in my project because I have fantasies of creating a
Puppy like project using LFS. AUFS is used by Puppy Linux along with squash
fs in order to load the operating system, optional software packages and a
personal files layer as separate layers of the file system. So changes to
personal files or installing of programs by an end user can be entirely
undone because it does not overwrite the OS layer, which is loaded as a
read only AUFS layer.

3. It may only be on my hardware, but I had to add some other code to the
INPUTRC to support my home and end key codes:

# for my box
"\e[8~": end-of-line
"\e[7~": beginning-of-line

4. I didn't create that text so, if it makes sence to change the
wording that sounds good :)

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
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

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
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 your own pace. But then the ./build
script itself is open to change as well if you like.

Version control is a good idea. I see git is being used by ericherman
<https://github.com/ericherman> which is fine. I have exprience with
SVN personally.

Thanks again for your feedback, I hope I didn't miss addressing any of
your points.

Take Care,
Robert Taylor

P.S. my spell checker seems to be broke sorry for any errors etc.

On Sat, Oct 5, 2013 at 2:09 PM, Dan McGhee <beesnees at grm.net> wrote:

>  On 10/04/2013 01:57 PM, Rob Taylor wrote:
>   I have updated the wrapper scripts to handle some new chmod
> functionality. It now supports OCTAL-MODEs that are longer than 4 digits or
> have preceding @ signs.
>  See:
> https://lists.gnu.org/archive/html/bug-coreutils/2012-03/txtWUJXdGwYNs.txt
>  Where it says: " chmod, mkdir, install now accept new style of octal mode
> specification. When octal mode is preceeded by @ or is 5+ digits long with
> leading zeros, it can clear the set user id and set group id bits on
> directories."
>  Get the latest "more_control_helpers.tar.xz" file from
> https://www.javacrypt.com/lfs/
>  Thanks,
> Robert Taylor
> On Mon, Sep 23, 2013 at 2:08 PM, Rob Taylor <rtaylor777 at gmail.com> wrote:
>> Thanks for the link Hans.
>>  On Mon, Sep 23, 2013 at 12:51 PM, hans kaper <spakyelj at xs4all.nl> wrote:
>>>  Op Mon, 23 Sep 2013 21:05:01 +0200 schreef Rob Taylor <
>>> rtaylor777 at gmail.com>:
>>>    I have been working through LFS 7.2, 7.3 and 7.4 testing and
>>> revising scripts for this package management system.
>>>  I have added a number of scripts and in some cases almost entirely
>>> rewritten the existing scripts. While I have tested these scripts no one
>>> else has so, my version of this package should be considered Alpha or Beta
>>> at best.
>>>  You can play with the revised project and see my notes here:
>>> https://www.javacrypt.com/lfs/
>>>  Another interesting piece of work on this subject you can find at
>>> https://github.com/ericherman/package-users.
>>> There was also a discussion on this subject on this support site about
>>> two years ago, initiated by Drew Ames.
>>>       Robert--
> Great job on this hint!  I've used it since .the first time I ever built
> LFS.  After a hiatus, I'm gearing up to do another build and saw this
> e-mail.
> I read your "new" hint, comparing it to the old one, and reviewed your
> scripts, build and build.conf.  They are really, really elegant.  I'm
> impressed.
> I have some questions and comments.
> 1.  My first comment is constructive criticism.  You have not taken credit
> for your work, either in becoming the maintainer nor in the improvements
> you've made.  I urge you to identify yourself as maintainer at the beginng
> of the hint and take credit for your improvements in the Change Log.
> 2.  Is it a personal preference to us AUFS? Or is there a technical
> motivation?
> 3.  Is there something other than making a "pretty prompt" in the terminal
> that you added INPUTRC to a user's environment?
> 4.  The last sentence of Section 5.10 "ldconfig.c" says, "Because it
> doesn't evaluate any user input and doesn't pass any user-provided data
> to ldconfig, it can safely be made setuid root. I'm assuming that the
> first "it" refers to ldconfig.c and the second "it" refers to ldconfig.  Is
> that corrrect? If it is, I recommend changing the end of that sentence to
> read, "...ldconfig, which can, then, safely be made setuid root."
> 5.  Do you install 'shadow' as the first package after chroot so that you
> could get "su?" If so, since the hint tells you to copy 'su' to
> /tools/bin in Ch. 5, I'm wondering what advantage there is, especially
> since it causes some "hiccups" down the road.  But, then, that may merely
> be an approach different to mine.
> 6.  And that's a good segue to this comment.  You designed your build
> script to continue through to completion regardless of errors--at least
> that's what I think I got from reading your build notes.  I've found that
> unless I make a dumb mistake--copy and paste takes care of most of those
> :) --the only interrupts I had were about the lack of install_dirs or
> permissions like '-o root'  I've written a build script which is not
> nearly as elegant as yours, but recovers from failed "make" and "make
> install."  That way, I can fix problems as they occur.  When the build
> completes, then, I'm done and don't have to do anything extra with
> errors.  Mine also "pauses" after running a test suite so that you can
> examine the results in a text window before proceeding. [interruption] Think
> I'll add that pause after 'configure' and 'make' so I can review *.err
> logs.[/interruption]
> If you don't mind, I'm going to plagiarize some of your ideas to "spruce
> up" my script.  I will send you the script as it exists now, while I'm plagiarizing
> :) , if you'd like to review it.
> Lastly, Hans talked about a discussion on this list a few years ago.  I
> was part of that along with Drew.  We were exchanging many, many ideas.
> One of those was "version management" for upgrades.  If he's still around,
> I hope he jumps in here.
> I hope you have not reacted negatively to anything I've said here.  You
> have done a great job.  Thanks.
> Dan
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20131005/5ef6c8c8/attachment.html>

More information about the lfs-support mailing list