Packaging Guidelines: Why so lax for BuildRoot?

[Michael Schwendt]

On Mon, 24 Mar 2008 12:08:30 -0400, Dimi Paun wrote:

> 
> On Mon, 2008-03-24 at 12:23 +0100, Michael Schwendt wrote:
> > Oh, interesting, then you're one of the very few who really ran into
> > it. It was mostly a theoretical problem, because users had to define
> > %buildroot themselves to get "rm -rf /" and also build as root.
> 
> Hey, this happened many years ago (maybe '97), so I don't recall exactly
> what I did, but I didn't have to go through too many hoops :)
> 
> Regardless, my point is that it pays to think about interfaces and
> encapsulation, and this one is such an obvious fsck-up that it should
> have been painfully obvious from the very beginning. 
> 
> It's still surprising that it managed to resist for so long.

The first buildroot sanity checks were added in the 90's already, too.
For commands like "rpmbuild --buildroot / ..." you get an error.
There's still a "backdoor", though: rpmbuild --define 'buildroot /' ...
and no default buildroot.

But you can shoot yourself into the feet also with a redefinition of
other essential macros. More often than somebody got "rm -rf /"
as superuser because of an RPM buildroot definition, I've seen users
damage their installations because Makefiles and other build-scripts
did not stay in a buildroot but modified the system installation
directly (and e.g. removed files there).

> What would happen if rpmbuild would define %buildroot by default,
> and make it immutable? Then we could just sed through the .spec
> files and nuke its definition from there...
 
First find a solution where the default buildroot is easy to find by the
packager (not a temporary solution where mkstemp usage leads to lots of
similar buildroots that are not deleted automatically) but is also cleaned
up automatically by rpmbuild -- unless it's explicitly requested not to
clean it.