Wayne Blaszczyk wrote: > On 19/11/11 08:40, Bruce Dubbs wrote: >> Wayne Blaszczyk wrote: >>> The Cups installation instructions failed for me if I try to do it for >>> the second time, around the mv command. (i.e. directory not empty error) >>> Can we put in some logic around this so that the instructions are >>> repeatable? >>> Maybe replace the move with a copy, then delete? >>> The reason why I suggest that rather than an if directory exists >>> statement, is the possibility of the documentation changing based on the >>> different dependencies being installed at the time from the previous >>> install.
>> Does mv -vf /usr/share/doc/cups /usr/share/doc/cups-1.5.0 work for you? > Wouldn't that copy the cups directory inside the cups-1.5.0 directory if > the directory already existed? Yes, it does. I guess we need: rm -rf /usr/share/doc/cups-1.5.0 mv -vf /usr/share/doc/cups /usr/share/doc/cups-1.5.0 >> As for the useradd, I never think of those being scripted. If you want >> it in a script, just don't add a && and it will print out the error, but >> continue. >> >> I don't really like the GDM construction. There's about 30 places in >> BLFS for useradd/groupadd and going back and putting an if in all those >> doesn't seem like a good use of time. > I could do it if there was no objections. Yes, I do prefer it not to be there. Although we can script lfs, I think blfs is a different product and the objective should not be scripting. If is was, there are a lot easier ways to do it. > If you do have objections, then that's fine. I'll just put more fuzzy > logic into my script generation process. I'd probasbly write something like: [ grep -q ^name /etc/passwd ] || useradd .... -u name I wouldn't have a problem with puting something in the xml that could be tested like: <screen role="root"><userinput role='useradd:lp'>useradd -c "Print Service User" -d /dev/null -g lp -s /bin/false -u 9 lp</userinput></screen> that could be used to automate custom scripts. > This is one of the main reason I don't like doctype being used in this > project. It has too much freedom, and therefor make things too vague in > certain areas (to a non human). It's not precise enough to define > something exactly with simple language. I don't follow that comment. Too much freedom? >> If a user knows enough to script it, then he should know enough about >> how to handle this type of thing. > I agree with that , but in my case it is a script that creates the > scripts from the blfs xml pages directly. i.e. I'm trying to automate > the whole thing so that it can run overnight builds without any human > intervention. This process does stop when it encounters errors (except > for 'make checks' and alike). The whole idea behind xml is so we can do our own thing. One source that can create html chunked, html single page, pdf, text and on top of that, create things like wget lists, patch lists, jhalfs scripts, etc. Yes, it's complex, but it also gives flexibility and, probably the most important aspect, consistency. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
