Hi Dan,
> As far as "window management" goes, I've used Windowmaker since my first
> {,B}LFS build--all with package users I might add. And I really like
> this manager. It's light-weight and fast. There's quite a bit of
> configuring, especially if you want to use a menu system, but once it's
> done it's great. The problem that I had with it was that it wasn't being
> developed for awhile and maybe in the "functionality" realm it left a
> lot to be desired, but it still worked. I checked the other day and
> development has started again. I haven't gone so far as to check
> releases, but I'm intending on using it in my current build.
Hmm, thanks for the tip. I was thinking about going with Enlightenment.
It's not covered in the BLFS book, but the screenshots I've seen of
Enlightenment look very "pretty", comparable to Gnome.
> I think that this is the major "frustrator" in this system. I just never
> thought of your idea. I do when I want to start a new build generate a
> new "installdirs.lst" for inclusion in package users. It heads off a lot
> of failed installs. Have you tried scripting it yet? I've got an idea
> that might work if you haven't.
I've done it 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.
> 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.
> At the very least this will probably mean an update in the hint and
> changes to the "Build" script. The hint needs a little polishing now
> based on a current LFS-SVN build. If someone (you......me? :) ) were
> contemplating this, I think we should contact Matthias and see if he'd
> mind. The last change was November, 2005, and I haven't noticed him
> respond to anything in a number of years. The hint is not listed as
> "orphaned."
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.
> I have modified the "Build" script so that it finds and untars the
> package. It <cd>'s into the directory, does it's thing, makes logs of
> all--including tests--and cleans up after itself by removing the source
> tree. I still enter all the commands from {,B}LFS with "copy and paste"
> to the appropriate sections of the script. Oh, the script will also take
> up where it left off on a failed configure, make, test or install.
That sounds similar to what I've got going on, although I still manually
remove the source tree rather than automatically deleting it. I also
haven't set things up for recovering from errors, as I would normally
rather do a complete rebuild if there are any problems.
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'.
> Tim, thanks for the thought provoking message.
My pleasure, and thank you for engaging me in this interesting topic :-)
Cheers,
Tim
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
