S. Anthony Sequeira wrote:
Hi all.
A recent problem (xorg build attempting to overwrite fontconfig configuration
files) led me to investigate further. I believe the problem arises because
I'm attempting to use the routine improperly.
If I understand what you are doing, you have arrived at a point similar
to the one at which I abandoned the pkg-user hint. Your situation of
the fontconfig configuration is very close to the "unintended
consequenses" I suffered as a result of using the hint. I found that I
lacked both the time and desire to delve so deeply into my builds.
However, I developed a procedure that used this hint as a basis for my
package management system.
The build script calls three functions configure_commands(), make_commands()
and install_commands(). This is cool.
However they are called thus
{ function 3>&1 1>&2 2>&3 | tee function.err ; } &> function.log
<snipped the bash analysis. It was great>
This is NOT a problem, unless one of the functions sets a variable, or cd's to
a directory (typically in the configure_commands function, the way I use it
at least), and the variable needs to be accessible later, or later commands
need to be executed in the new directory.
I'm attempting to find a similar construct which will execute in the current
shell (no pipe to tee).
In the meantime, if anyone could inform me as to where I'm going wrong, I
would be grateful.
I think your analysis is quite correct, and I don't think you're going
wrong. What I did was break the build script into its .configure, make
and make install components. I named them blfs-configure, blfs-make,
blfs-make-install (creative, huh?!?!). These reside in
/etc/pkgusr/skel-package. I hacked the configure and install scripts to
include 'touch $PWD-time1' and 'touch $PWD-time2' respectively. This
preserves all of the logging and file building that you desire. The use
of 'tee' still exists, but breaking the build script apart and running
each in its own shell seemed to solve the shifting variable and
directory situation.
I create a directory in /usr/src for a package, copy the scripts into it
and untar the source file. I then edit these scripts with necessary
items that the direction in the book gives. I put 'prefix=/usr' in the
base configure script. The command from the source tree is
'../blfs-configure' and so on using my terminology. Of course, 'su' to
root for make install.
I would like to log *all* the build commands, with the current methodology
(stderr -> file.err and stdout+stderr -> file.log). Otherwise, the easy
solution for me is to place any such commands outside the function call group
commands (if you catch my drift)
The completion of the build addresses your "drift," I think. :)
Using my method you now have /usr/src/some-name/sources. In
/usr/src/some-name, in addition to the source tree, you also have
{configure,make,install}.{log,err} and sources-time{1,2}. However,
install.{log,err} and sources-time2 are owned by root. I 'chown
myname:mygroup' those two files. Now I'm ready for the file.log. I got
this idea from Randy McMurchy when we discussed this issue a few months
ago. I use the following command as root:
'find / -xdev \! -user me -newer sources-time1 \! -newer sources-time2
-print > file.log'
You could modify this command to get all the directory, man and bin
stuff that the original build script gets you. But it does give you all
the things that you just installed. If there are any additional
commands in the book, a simple 'touch sources-time2' as root, when
you're done, allows the find command to retrieve these files too. I use
the \! -user modifier because with out it 'find' adds all the files that
./configure and make generate.
What I lose with this method is the delete_package of the hint. For
packages that have a 'make uninstall' target this is irrelevant. For
those that don't the files.log can be used to delete the files either
manually or with scripting. Additionally you could add an '-exec' to a
find command. I can also preserve configuration files that may be
over-written by an upgrade.
I'm not sure that I've addressed your situation precisely and I hope I
haven't muddied things to terribly much. For bandwidth reasons, and
also for a few well-placed four letter words, I haven't included the
scripts with this e-mail. I can send them should you desire.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
