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.
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. re: 1 and 5... I didn't alter the text of the hint itself (supplied on the http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txtpage), 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 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. 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 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 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 <beesn...@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 <rtaylor...@gmail.com> wrote: > >> Thanks for the link Hans. >> >> >> On Mon, Sep 23, 2013 at 12:51 PM, hans kaper <spaky...@xs4all.nl> wrote: >> >>> Op Mon, 23 Sep 2013 21:05:01 +0200 schreef Rob Taylor < >>> rtaylor...@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 > >
-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
