Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
Well I've searched around a fair bit about the dangers of installing as root, and understand that you shouldn't use root until you have to make install. However, the /usr/src directory has write access disabled for all but root. So how am I supposed to compile the source as a user if I can't even extract the source to the directory? I suppose that I could extract the source as root and then run the commands as a user? I am unclear as to whether these commands will fail though since they can't write files to that directory.
For example, I just installed the latest release of ALSA and it works. However, I went through the whole procedure as root. The ALSA driver works on my user account, so I don't know if it's really necessary to uninstall and start over from a user account. I'm running Slackware 10.0 btw.
1. Have a normal user download the tarball, extract it within his/her own home directory, execute the configure script, and then issue make. Then when you want to install, become root, issue the "make install" and move the source to /usr/src or wherever you want to keep it. There's no rule that says the source must be compiled from the same directory you store it.
2. Change the permissions of /usr/src to something like root:softinst (root=owner, softinst=group). Change the permissions to 77X (where X can be whatever you want, but I would suggest 0). Make a regular user part of the softinst group and re-logon with that user. Then all members of the softinst group can save/extract tarballs inside the /usr/src directory
Thanks for the help. I was uncertain if the source files were supposed to be in the src directory for any reason other than convention. I think I might go with your second suggestion, as it seems a bit more convenient after I get it setup.
Generally speaking, yes, convention suggests you keep any source trees inside an src directory (/usr/src, /usr/local/src, etc.) In fact, the convention goes so far as to suggest placing source trees for basic system programs in /usr/src (the kernel, core utility packages, and anything else needed to boot the system into a rescue mode), and that everything else should be installed in /usr/local/src. Part of that reasoning is, distributions are not supposed to touch anything in the /usr/local tree. So you could (in theory) reinstall a distro or install an entirely new one and everything in /usr/local would remain intact. It's not quite that simple, but that's the idea.
Also, you don't have to keep source tree around if you don't want to. You can re-tar them, and stick them somewhere (like /usr/local/src/tarballs) or you could just delete them entriely. I only keep the kernel source and anything I've hacked on. I re-tar everything else.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.