SlackBuilds (su) versus (su -)?
 

In the past I've always run a SlackBuild by simply becoming a superuser and they always worked fine, but when building ffmpeg recently I kept getting errors. Took me a while to figure out that I simply needed to (su -) and then everything worked perfectly. Just wondering if someone could give this newbie a simple explanation as to why that is the case? I'd always assumed superuser (su) was the same as root?

check "step 3" here.

Thanks, Ponce... I should have RTFM!

That all makes sense now. Is there any reason to go back and redo any of my previous SlackBuilds or is the fact that they built and are running fine reason enough to leave them alone?

Jim

I think the motto "if it ain't broke, don't fix it" can apply also in your case ;)

I usually just use fakeroot (with my regular user's path adjusted). So far I haven't had an issue.

Hmmm - would you like to expand upon that?
I always have at least 2 terminal windows open where I've su'd to root - just makes it simpler that way ...
I'm interested in how you use fakeroot ...

fakeroot was created to simplify packaging as a regular user. It creates an environment where apps running under it believe that they are running under root and all files appear to them to be root owned by default. Additionally it will do a few tricks like allowing things like chown to appear to work. File ownership will not actually change but apps running under the fakerooted environment will believe that ownership has changed. Because you are not actually root there are of course limitations. For example you still have no permission to modify or delete files that your real user could not modify or delete.

The purpose of all of this is that it means you can create packages with correct permissions and ownership without actually having to elevate privileges. This prevents a badly written (intentionally of otherwise) build script from wrecking havoc with your system. This is not really an issue with SlackBuild scripts from the Slackware sources/ directory (we all have to trust Pat anyway) or scripts from SlackBuilds.org given that the SBo team double check the submitted build scripts (though it does have the minor advantage that you don't have to enter a password to run fakeroot). Where fakeroot is truely helpful however is when you are making/running your own build scripts, as a badly written script cannot install or modify anything in directories it shouldn't (unless your regular user had write access to that area of your filesystem). Also handy if you stumble across a useful looking SlackBuild elsewhere on the web (e.g. sometimes people will post a script on this very forum). You should of course read any script before you run it but using fakeroot serves as an extra security step for anything you might have missed.

The traditional way to to deal with the above issues is to comment out any chown lines and run the script once as a normal user (checking it does nothing crazy), then renable any chown lines and rerun the script (or at least do the chown manually and rerun the makepkg step). Using fakeroot saves you having to do the build and/or packaging twice. Therefore fakeroot is not essential (you can do without it) but it is certainly a handy time saver.

@ruario:
takk skal du ha! :-)

@perbh: bare hyggelig! ;)

@ruario

Excellent description of fakeroot; very well done.

Thank you.

cheers,

The two uses of su -- su and su - differ.

su by itself gives you root access but uses your environment settings.

su - gives you root's environment.

As a bonus, you can become somebody else (other than root).

su - -l username logs you in as "username" with that user's environment settings.

What the dash has traditionally been for is to "as if you logged in on the console as user," mostly having to do with environment settings (so, if you're using KornShell and log in as a user who uses C-Shell, you'd get that user's environment -- totally different than KornShell, Bourne shell, BASH or whatever). And, when you log out from that user account you do not inherit the environment of that user (your home environment does not get all screwed up in other words).

When I build packages from SlackBuilds.org, "su -", change directory to where the source and SlackBuild is and execute the SlackBuild. When it finishes, I "installpkg/upgradepkg" the .t?z in /tmp then move that file to the current directory, then exit (so I'm back to my own account in my own home directory).

Hope this helps some.

Thanks for all of the great information, folks. I went back and rebuilt some of my software packages like Transmission using (su -) and now I'm not getting GTK error messages anymore when I start them from the command line. I assume it has something to do with the PATH being correct and from now on I'll be running all SlackBuilds in 'real' root. Appreciate all the input here.