LinuxAnswers DiscussionThis forum is to discuss articles posted to LinuxAnswers.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Distribution: Red Hat 8.0 (Home), Red Hat 8.0 (Work)
A most helpful article, however I would really like to see an article on how to compile on any RH version, since they seem to make it their mission to create a distro where compiling anything is impossible.
The trick to compiling on ANY distro is to have the development packages installed, this would be things like GCC, make, binutils... The reason RH and some of the other RPM based distros tend to leave these out is because they provide RPMs and would expect you to use those RPM's provided. It's just a different way of thought. They still do provide the GCC et al tools, you just have to install them yourself, or rather, knowingly install them.
This is probably considered as close as it gets to "make uninstall". Which brings me to my next point:
This is sometimes an option that the programmers will put into the Makefile. If they do, lucky you, all you have to do is type that when you are ready to remove the program and you are done.
The main reason for sources not having a universal way of being removed is that during the make install process they are simply copied over to the necessary locations. If the developer didn't write a make uninstall to rm everything from those locations, there is no way for your system to track them (without something like checkinstall).
Other options are available for things like this, check the LFS forum on this board for more info.
Distribution: Slackware, (Non-Linux: Solaris 7,8,9; OSX; BeOS)
I hope I don't say anything so harshly that it offends, it's not meant to.
I ASSume that this is geared toward people who have never installed from source, so I'm critiquing it as such.
Once downloaded you want to do the following:
tar zxf linuxquestions.tar.gz
I disagree with the ordering.
The first thing you want to do is read the README (or equivalent) file and learn what special needs this program has (libs, make arguments, env vars, maybe it doesn't use autoconf, etc.). I guess this would be the second thing, after untaring the package.
The next thing you want to do is follow the instructions in the README on how to build the package. While autoconf is quite popular, it's not the only way to build and distribute a source package.
In the HOW-TO, the note about the README and INSTALL files seems a little lost. Basically, I think that needs to be more obvious and expanded upon.
After reading the README, ./configure --help should be, in my opinion, run. Again, this is mentioned in the HOW-TO, but most READMEs don't actually say much about all the possible options, and the best way to see what you have available to you is via configure (if that's even available).
The user should learn as much as possible about the package they are installing before they jump in and start dealing with error messages because, "bash: ./configure: No such file or directory".
Non-uid0 users can't usually write to /usr/local/src, so maybe you should recommend a "sandbox/src" directory under their home dir for downloading and building packages. Or, one would have to change permissions on /usr/local/src. I have both a ~/sandbox and a /opt/src directory available to normal users. /opt/src is for global packages, and ~/sanbox is my personal playground. Non root can write to /opt/src, of course.
Maybe mention that ./configure --with-blah can enable option blah that wouldn't otherwise be enabled.
You might also consider recommending checking MD5 sums if they exist. This will help to bypass any problems with long downloads, noisy lines, cracked hosts, etc.
Just a few of my comments, I'm sure I could come up with more. . . I like it so far, but it does need work--it's always great to have a start.
Great article. Left me with a few questions though:
I have been untar-ing my source files in random directories inside my Documents folder and compiling from there, rather than using /usr/local/src. Apart from being a little messy, is there any harm in doing that?
Once the (./configure, make, make install) process is complete and the app is working correctly, can you safely delete the source files?
Is there any need to close all open apps before installing?
Is there any need to re-boot after installing?
Must you install as root or can you install as anyone?
Just a guess, but are you coming from a windoze background
It's a good habit to get into to untar your files in a central location, just for ease of locating them and keeping the system tidy, but with my experience I've not had a problem untarring files anywhere I can and using it from that location to do the rest of the work to get it installed. Just choice.
Yes, removing the source to save space is a great way to gain back a few hundred MB sometimes. However should you need to uninstall the program, it's usually a good idea to at least keep the tarball handy.
No, you don't normally need to close all open applications You might consider doing that on MAJOR upgrades of important system files, but as a rule, no. If you are upgrading an open package and you can shut it down, it's probably a good idea to.
Re-booting is a thing of the past my friend. I install applications constantly on my server, yet I have an uptime of over 50 days (and that's really low). No, there is usually no need, the only exception might be the kernel and there are those who have said they don't even need to when they do that.
You don't have to be root, however you will need root privileges. Search the board and read up on 'sudo'. It's using a user, given certain permissions, to do things that root would normally do.
1) no it's ok, but very messy. there are real benefits from using a standard location though.
2) you can, yes, but you would be advised to leave it there if you wished to uninstall it. jsut go back to that directory and run "make uninstall" and the application will be removed normally. (this is a per program basis though and not controlled in any way). to reduce spoace you can run "make clean" to delete the temporary compiled data in that directory if you wish.
4) nope, unless it's a really core piece of software like glibc (which you really don't want to go near)
5) installing as you will mean you can only install it in places you have access to. on a very large nertworked system people may install their own software to /home/user/bin or a similar location they create themselves. this alternative location would be specified at ./configure time. e.g. ./configure --prerfix=/home/user/bin. it's best to configure and make as non root for mild security benefits, but actually installing them in /usr/bin or such like will require full rioghts to those locations, which *only* root should ever have.