dbn.lists at gmail.com
Sun Aug 12 09:23:56 PDT 2007
On 8/12/07, Cubo Aula Info <ilfigliodellaparolaavuoto at gmail.com> wrote:
> I have looked paco, I was curious to know if this
> % (from man paco)
> % Due to LD_PRELOAD limitations, paco can't follow the trace of suid pro-
> % grams.
> % For the same reason, paco does not work with programs that statically
> % link libc.
> can create problems to a normal blfs installation and if those
> problems are avoided with the method suggested by Dan (fakeroot and
> then paco) :
> make DESTDIR=$dest install
> paco -lp+ $program "tar -C $dest -cpf- . | tar -C / -xpf-"
This was the original reason I started doing this, but it's rare that
this is actually a problem. The only package I know of where you're
using a statically linked binary during the installation is glibc. It
creates it's symbolic links in /lib with a static binary (since it may
replace the existing dynamic linker, wreaking havoc). This results in
a few unlogged files during glibc. But if you only install glibc once
at the beginning of Ch. 6 (which you probably should do since
reinstalling glibc is risky), then you can just run a find on /lib.
find /lib -name "*.so" | paco -lp+ glibc
The DESTDIR has a lot of power, but also a lot drawbacks. It's the
simplest for bundling a package since you avoid interaction with /.
Also, it's nice when you want to make further adjustments such as
moving files. But it causes problems when part of the installation
process expects to use the files it has just installed, often when
rebuilding a cache file like /etc/ld.so.cache. Since you didn't really
install it to / yet, it won't work. You end up having to recreate many
actions after your real installation. This is the main reason for the
%post directive in rpm.
Read the fakeroot hint for more details. If you just want to get
started, I'd suggest just using paco on its own. The drawbacks are far
outweighed by the simplicity and power.
More information about the blfs-support