SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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?
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.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
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).
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.