[lfs-support] [LFS 7.2] [Chapter 6] Symlink Style Package

Charlie Brown stieizc.33 at gmail.com
Sun Jan 27 21:00:45 PST 2013


Hi Stephen,
I am a beginner of linux myself so maybe I would say something wrong...
#1 - Have I understood the process correctly?
I think yes.:)
#2 - Will this method, including the script, work as expected?
Well, maybe you will realize some problems when you implement this method.
1). Some packages doesn't come with the DESTDIR variable. You may have to
double check the Makefile. Sometimes READMEs and INSTALLs in the source
directory don't tell you there is a DESTDIR variable, but there is.
Problems comes when there really isn't such a variable. I think e2fsprogs
don't have one.
My stupid solution is to change prefix to /tmp/foo and find out what would
be installed, and then make install, then collect the files shattered in my
system. That's really stupid and couldn't get the security benifits of
symbolic style management. Maybe you can try user-based management as a
supplimentary method.
There are many reasons for the absence of DESTDIR variable. An analysis can
be found here<http://www.dwheeler.com/essays/automating-destdir.html>.
Some other strange stuffs... glibc uses install-dir variable instead. But
DESTDIR also works?
My final gcc in 6.17 would give different output for the test command
"grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log".
Instead of
"/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crt1.o succeeded"
It would say
"/usr/lib/crt1.o succeeded"
I am confused even now. But I did some searching and decided that that may
not be too severe a problem, and I never find
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crt1.o in my good old host
system, even when it tells me that it did find it there, and I just accept
it. If you know why all these happens, please tell me.
2). I guess - as I am not really familiar with the boot process I can only
guess - one of the situations in which symbolic style would cause trouble
is that you have /usr on a different partition and you have a symbolic link
in /sbin to /usr/pkgs/foo-bar/sbin/some-important-stuff. I guess the system
won't start in the cases for programs like init and fsck, etc. So I decided
that putting all stuffs in /usr/pkgs/ is dangerous ( I may be severely
mistaken ) So just in case I make a directory ./pkgs in /bin /sbin /usr
/lib, and use a script to put things as they are, respectively. I have to
repeat that I may be totally wrong. If I'm wrong, yell at me.:)
This separating method has at least one defect. The symbolics in the
original package like /usr/pkgs/abc-xyz/lib/foo ---> ../../lib/bar.so would
be totally broken. Be CAREFUL.
3). I'm really poor at reading and writing scripts, so I figured that I'd
better use someone else's script. Currently I'm using graft. I think it's
pretty good.
4). You may want to keep a log of all errors during make DESTDIR install.
When I accidentally skim through the output of make DESTDIR install one
day, it said that it couldn't generate /usr/share/info/dir. While that's a
fairly small problem(lfs book give us a script in 6.60), I am concerned
there may also be something big.
#3 - Is it actually necessary to soft-link to *every* file in
'/usr/pkg/<pkg_name>/<pkg_
number>' from the root tree, or is that
overkill?
I put stuffs that should appear in /var and /etc as where they should,
instead of soft linking them. I now regret a little about my decision with
/etc, which is now very messy. In the case of ldconfig, it would generate a
/etc/ld-cache file overiding your old symlink. I was moved by its strong
will and decided to remit the sin of /etc. Another concern is that I want
to keep all my configs and don't want to delete them accidentally by
uninstalling the package.  As for /var, I simply just want to leave it as
it is.
I leave the docs in /usr/share/doc. I don't think there is a need to
symlink them.

Good luck!
Charlie
-----------------------------------------------------
Here is my script to handle packages with graft, just in case you need it.
I'd be grateful if you point out where the script can be improved. At least
the argument checking part is poorly written.

#!/bin/bash
# Put sub directories /usr/pkgs/foo-bar.bar/* into /*/foo-bar.bar, and
automatically graft them! Maybe a log should be made for autoungraft.


ROOT_UID=0
E_NOTROOT=87

# First check uid
if [ "$UID" -ne "$ROOT_UID" ]
then
    echo "Must be root to run this script."
    exit $E_NOTROOT
fi

E_WRONGARGS=85 #bad argument

#Test whether the argument exists
if [ -n "$1" ]
then
    pkgdir=$1
    pkgname=`basename $pkgdir`
else
    echo "Must take an argument, which should be the full path of your
package"
    exit $E_WRONGARGS
fi

# Test if pkgdir is a path
if [ -d "$pkgdir" ] # This is not secure when their is a directory under
the current with the same name $pkgdir
then
    cd $pkgdir
    ls
else
    echo "The argument should be the full path of your package" # Which is
actually not necessary
    exit $E_WRONGARGS
fi

# Remove $pkgdir/usr/share/info/dir if exists.
# I will generate /usr/share/info/dir whenever I like.
if [ -e usr/share/info/dir ]
then
    rm -v usr/share/info/dir
    echo "$pkgdir/usr/share/info/dir removed"
fi

# If $pkgdir/usr/share/doc/* exists, then move them to /usr/share/doc/
if [ -d usr/share/doc ]
then
    echo "Handling doc"
    mv -v usr/share/doc/* /usr/share/doc
    rm -rfv usr/share/doc
fi

# If etc, var exists, move their content to /etc and /var respectively
for dir in etc var; do
    if [ -d $dir ]
    then
        echo "Handling $dir"
        mv -iv $dir/* /$dir
    fi
done

for dir in bin sbin lib usr; do # Still no way to handle conflicts during
graft process. Have to resolve them before running this script
    if [ -d $dir ]
    then
        echo "Handling $dir"
        if [ ! -d /$dir/pkgs/$pkgname ] # Check if destdir exists
        then
            mkdir -p /$dir/pkgs/$pkgname # if not, make it
        fi
        cp -R $dir/* /$dir/pkgs/$pkgname # i.e. move foo-bar/bin/* to
/bin/pkgs/foo-bar
        graft -i -t /$dir /$dir/pkgs/$pkgname # graft the moved dir
    fi
done
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20130128/77e26a45/attachment.html>


More information about the lfs-support mailing list