bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tar --no-same-owner (design bug)


From: Bob Proulx
Subject: Re: tar --no-same-owner (design bug)
Date: Fri, 7 Jun 2002 13:46:26 -0600

This is getting off thread...

> btw: "make install" needs to be executed as root in most cases. So errors
> in development makefiles and the like can harm the operating system
> anyways.

It does not need to be run as root if you are installing into an image
area and not into the current live running system.  I imagine your
chroot comment indicates that your install into a live area is really
a chroot'd area off to the side.  It is my own opinion but instead of
doing that I recommend doing the other option of changing the install
location of the makefile.

Most packages are using automake these days which allows either
DESTDIR or prefix to be an override.  Of the ones that don't use
something like that you would have to tweak the makefile.  'make
DESTDIR=/var/tmp/pkg-build' and away it goes.  Package builders and
AFS admins like DESTDIR because it is simple direct and to the point.
But few packages are new enough to support that yet and so usually it
is prefix= instead.

I repackage a small number (~200) free software packages for hpux and
none of those need root to build the package at the 'make install'
step but probably five need a makefile tweak to support redirecting
the target installation.  I keep the makefile tweaks as either patch
files or sed scripts as appropriate and moving to newer versions are
usually fully automated.

Then I can test on victim machines which are installed as root and can
do anything.  But those get reflashed to scratch routinely as part of
testing.  If something there goes bad I can fix the package and try it
again from scratch in a few (~30) minutes for a complete new system.

> In a ROCK Linux standard configuration I'm building more than 500
> packages as root without any troubles. If there would be any
> problems in a makefile which actually could destroy anything, it's
> very likely to be in the command-tree for "make install" ..

Ah, life on the edge!  :-)

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]