I maintain my own software stack in /usr/local - applications that don't come with the operating system, or different version of ones that do.
I was just updating gzip. So the ./configure script, when invoked with --help, says:
By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc. You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.
OK, so I do ./configure, make, make install.
What the heck?!?!?!
It's installed it in /usr, overwriting the system copies!
Looking at the configure output in more detail, it did say:
checking for prefix by checking for gzip... /usr/bin/gzip
I know I can't blame autoconf itself for this one, because the tool has been misused, but using a tool and then violating both its common conventions (default prefix of /usr/local) and its own self-documenting behaviour, is really bad.
And one last thing. It installs itself as zcat, not gzcat. On Solaris, zcat isn't even the same beast.
1 comment:
Absolutely insane. Unbelievable. I've always worried about packages messing with my system in unexpected ways during installation, but I've never seen anything like this.
AFAIK, on Linux, you can run make install under Plash, and only allowing write access to /usr/local.
I'm not sure if any similar tools exist for Solaris. Perhaps you could create a non-root user who has write access to the /usr/local hierarchy but not /usr. (Programs that are normally installed setuid may or may not get the setuid bit set properly, though.)
What I do these days is use slashpackage-foreign to install each package under a separate prefix. I can create the package's directory as root and then change its ownership to the non-root user before installing. This works pretty well for me.
Very interesting entry---thanks for writing!
Post a Comment