On 09/23/10 11:50:19, Alan McKinnon wrote:
> Apparently, though unproven, at 10:55 on Thursday 23 September 2010,
> Helmut 
> Jarausch did opine thusly:
> 
> > Hi,
> > 
> > when portage installs a package, it first installs it into some
> "shadow
> > root". Then it records all files installed before it moves the 
> files
> to
> > the "real root".
> > 
> > I have to do some installations on SUSE systems (which are not
> > administered by me) and I'd like to imitate that procedure there.
> > 
> > Can anybody tell me if it's not too complicated and if yes, how to
> > achieve this (on a foreign system like SUSE).
> > 
> > Many thanks for your help,
> > Helmut.
> 
> 
> 1. Remove all traces of yast and it's bastard brethren from the SuSE
> box.
> 2. Have three qualified sysadmins double check that you have indeed
> removed 
> every last trace of it.
> 3. PREFIX=/some/stage/dir/
> 4. ./configure && make && make install
> 5. find /some/stage/dir/ > some_file
> 6. move everything in stage dir to real dir
> 
> Why remove yast?
> Because it's a sneaky P.O.S. and goes to extraordinary lengths to 
> nuke
> all 
> your hard work done without it.
> 
> And how you deal with file collisions is up to you. Yast really won't
> like you 
> if you overwrite some config file with your own testing version.

Thanks Alan!
Unfortunately, I don't understand how this can work.
Simplify using PREFIX failed for me since many packages record the 
full path for configuration/data/help files etc. in the generated 
binaries or libraries.
When moving such an application/library it will still search for 
those files in the build directory.
I would image Portage uses some sort of chroot (then the pathes are 
identical)

Furthermore, I cannot remove yast since I'm only a "guest" on such 
boxes.
Normally I'd use a PREIFX=/usr/local/<MYAPP> but some application 
still install something into  /etc/ or similar and I'd like to catch 
these cases.

Helmut.



Reply via email to