On 07/30/2010 07:13 PM, Timothy Rice wrote:
> I've done it [automated making new install directories] in an ad hoc way for 
> one or two packages, and it seemed to
> work. I included the following in a "postinstall" command when building
> dhcpcd:
>
>     find /etc/sysconfig -type d -exec chgrp install {} \;&&
>     find /etc/sysconfig -type d -exec chmod 1775 {} \;
>
> I haven't gotten around to making it a systematic part of the default
> build script yet.
>    
Looks like the only difference in the logic between yours and my 'find' 
commands is that I "pretended" that I was looking at a new install after 
I'd built the system using package users. So, if you made install 
directories of every directory and package user created then you would 
need find only the new directories from a new package. (I hope you 
understood that. I almost don't. :) )

This thread has got me thinking and I'm actually disappointed that I 
used Jhalfs to complete my build. I'm thinking of starting over again 
and doing it manually with package users. I'll put the "make install 
groups" logic in my script and see if it works.
>> >  I'm curious as to what files should be "writeable." What are some of
>> >  them that you think should have this ability?
>>      
> I seem to recall running into problems with commands like "info", where a
> package needs to add itself to a central database. In particular, anyone
> here on the BLFS list may recall about a month ago, I was having problems
> with installing MySQL because of this problem. Another command I seem to
> have problems with is ldconfig.
>
> To get around such problems, I've currently got things set up so that the
> build script is always run as the root user. Most commands in the build
> process are then prefixed with,
>
>     su $package_user -c
>
> This makes sure that as many commands as possible are run as the package
> user, but admits the freedom to run commands like ldconfig as root if
> required.
>    
I just haven't run into anything like this except ldconfig. I've just 
gotten into the habit of running it after each package. You su command 
looks "elegant" though. When in your script do you invoke it or do you 
call the script after invoking it?

> I've contemplated contacting Matthias, but didn't feel confident enough to
> do an update all by myself. My background is maths&  stats, not CS, and my
> experience with LFS is currently limited to one successful build of LFS
> 6.5, plus a few packages from BLFS.
>    
After I rebuild manually, I'd be more than happy to work with you and 
update the hint.

> It occurs to me that if I was interested in automatically recovering from
> errors, then I would probably use makefiles. An extremely simple Makefile
> might look something like this:
>
>     configure.log:
>          ./build configure
>
>     make.log: configure.log
>          ./build make
>
>     install.log: make.log
>          ./build install
>
>     .PHONEY: clean
>     clean:
>          -rm -rf *.{log,err}
>
>
> Then if you've completed the configuration and compiling, and just want to
> redo the install process (for instance), make would find the "make.log"
> and jump straight to the installation step, but if you wanted to do
> everything from scratch, you could run `make clean; make'.
>    
This is precisely the logic I used. I just use a series of tests to 
determine where in the process the script is starting then just jump to 
the right series of function calls. I hesitate to demonstrate an example 
because without the variables of the script the tests don't make sense 
when taken out of context.

I meant to get started on my "by hand" build today, but didn't get 
around to it. I'm going to try to use the install directory idea. After 
a couple of packages, I'll let you know how it's working. That idea 
would save a lot of aggravation, especially when you get to BLFS--in 
particular Xorg.

Thanks again, Tim.

Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Reply via email to