Basic SxS Inferred Knowledge

From Mike Andrew / Pam Roberts

The information here is a series of principle steps you must know about. Some of the SxS material is elaborate. Not because we wish to make it so, but because the subject itself is elaborate.

As a result, if you're in that deep, then quote "unpacking a tarball", which would be a preliminary step, is NOT covered in that write up. It would simply add to the noise level.

Every SxS author is concious of the initial hurdle you face. They have wriiten an article because they are where you're about to go. They know you lack an understanding of the terminology, having a 'personal reference' or orientation, to linux buzzwords.

As Editors, we ensure step material is written in plain english. However, there are some comments, in some SxS material, that can leave you floundering. Our choices are to elaborate every SxS to such an extent that it becomes unreadable, or, Here is a list of assumed knowledge, and the means to obtain it. This is not a tutorial on linux. it is a practical guide to get you to the bottom line as quickly as possible with the relevant SxS in mind.

Expressions: DON'T TYPE LITERALS

 Although syntactically incorrect, graphical shortcuts are used because they save 1000 words. They have come about largely from people's use of the bash script language.

You will often find

do_whatever <name of something>

the <> brackets are simply a warning to you to not type name_of_something literally, but fill in the blanks as it were. What you're supposed to 'fill in' is in context to the material presented. You also don't type the <>'s

do_whatever [an option]

again the [] brackets are not typed literally but are used to indicate that an_option is well, an OPTION


(dot)(slash)(space)

prefix characters to some syntax can be expecptionally difficult to read. The lack of a dot (period, alias full stop in Real English) will destroy what you're attempting to do. Thus it is common to see the above wherever a(space)is(space)not(space)immediately(space)obvious.

the same comments apply that you do not type this literally but use the graphical character it repesents. If you don't know what a (dot) is, you're in trouble. Goi back to windoze and use a mouse.

type this ...

'uname -r'

the single quotes used in this example are very typical of NOT using them. They are simply used as a convenience and meant to mean 'type' the contents at a command console.

</rant>
</quote>
</important>

html lexicons like above are popular and a means of saying a lot, in a short space, about a former paragraph. Just like html, you are supposed to infer something extra about the preceding paragraph, other than the written word.

$HOME

If your usename, ie your login, is fred, the start of your world is in

/home/fred/

*everything* else is related to either the system, or another user. Take it as a given: you are NOT the only user of your system.

echo $HOME

tells you, other people, and as importantly, automated scripts, who you are and where to put things, for you.

The file /etc/passwd actually defines which 'folder' (eg /home/fred) to start in when you login, but that is esoteric and the above principle is sound.


"From the command line"
"Open a terminal"
Linux is command line oriented. Just like DOS and CP/M. Desktops and guis are foreign to the native communications between elements of a Linux system. Unlike Windows which has disconnected it's dos prompt (command line) from anything meaningful, even gui desktop's in Linux rely on the piping mechanisms of a command line to 'do their thing'. (for programmers, <stdio.h> is alive and kicking, even in a gui)

As a user trying to get something installed, the above phrase is used all the time. Hence, to achieve this wondrous state, you need to be able to type command line syntax. And to do that, you need to be in a 'terminal'. Aka console.

If you have booted your system into runlevel 3, you already are, a terminal. If you're using a desktop, then there are any number of terminal display programs 'out there'. Just one of which is Konsole (kde).

"edit"
"kedit"
"vi"
"emacs"
"joe"

This simplest of requirements can leave you floundering. First you may not know how to (what to use), second it's alias names are all too frequent. The worst editor you can use as a novice is vi. It is powerful, idiosyncratic, and a pita. (see acronyms on this site for a definition). A related cousin is emacs.

These two excellent editing tools are a unix programmers tools of choice. They are NOT yours. Avoid them.

What you need is a simple notepad editor (or one that behaves like one). To this end, you will often see

"Kedit this config file and ...."
the reference is to KDE's kedit editor, a gui applcation that can be as easily started from the command line by typing? kedit.
alternatively, on the desktop simply type ALT-F2 kedit

Joe is an alternative (and a good one) for those of you familiar with wordstar. Anyone old enough to have used cp/m would use Joe by preference.


SUPERWOMAN vs MERE MORTAL

"become su"
"as a super user"
"do as root"

This basically says the content must be done as the root superuser. At some stage in the process, it is a fundamental requirement for almost any Step. You can:


The criteria being that something about the SxS needs root privileges to perform. Obviously? Installing a new kernel is not something a mere mortal can do.


TARBALLS and COMPILES

"unpack the tarball"
"extract the tarball"
"download the tarball"

Tarballs are the primary method in Linux of supplying applications for your (or any other) machine. They normally contain source code and scripts, but could, unusually, contain a binary application. You are expected to snaffle that tarball from a site 'somewhere', extract it, compile it, and (sometimes) do whatever the instructions inside that tarball tell you to do. The purpose of an SxS is to take that further and explain HOW to setup the resulting information for YOUR system. Where appropriate, an SxS avoids the technobabble inside the tarball instuctions.


"download the tarball from ..."

Generally this is a hard link to a specific url where, in a gui such as konqueror (kde), simply clicking on that link will cause the download to take place. You are responsible for using common sense and placing it in some suitable area on your hard disk. You really don't require hand holding to that extent. However, it is recommended that you develop consistent habits. Such as either storing all tarballs (and their resultant source) in /usr/src, OR, a permanet $HOME directory.

A nice feature of KDE (and others) is that it will resume a 999 meg download from the place it left off, if the connection breaks. This generally involves simply clicking on the same url again, once communication has been re-established.

Quite often, through no fault of the SxS write up, the _specific_ tarball or url does not exist. A week in Linux is a long time, revisions occur every day.

Generally speaking, the revised tarball will be found at sourceforge, or rpmfind.net It is well worth your trouble to bookmark these two site-repositories. You are going to visit them frequently in your carreer as a penguin.

Alternatively, the SxS write up will probably contain links to a homepage of on the author / maintainer of the subject. Sane eg, Diald, eg, Linux kernel org. eg. It is up to you to do your homework, and, truly surf the net when the need arises. All that any SxS can do, is give you pointers into where you need to be. Don't give up simply because the url link is not where you expected it. It aint that tuff.


A note on CVS

CVS is outside the scope of this document, and, outside the scope of a newbie. However, you should be aware that an increasingly popular option instead of downloading a tarball, and, instead of downloaded patches or updated tarballs, or even rpm, cvs is used.

What happens is, under cvs, you are obtaining THE source that the developer is working on right now, today. There are variations on this theme, but essentially, once connected to a cvs server, you receive ONLY those files that have been altered. As fixes become available to your favorite application, you connect to the server, and THEN compile and carry on just like a tarball.

Be aware of cvs, you are going to start using it.


"extract the tarball"

TARballs are the linux equivalent of zip files in windows. Their name comes from an historical association with TapeARchiving. The methodology tools and programming used to archive material on tape is still in use today, because, it works. There is no reason to reinvent a very solid wheel.

A pure tarball is in fact nothing more than a concatenated, undoctored string of all the files within the tarball. However

tarballs almost always come compressed with xxxx.tar.gz   extensions.

and, a newer, bigger, better. faster, meaner cleaner compression

xxxx.tar.bz2

 (The linux kernel comes this way)

Regardless of how your tarball is compressed, the karchiver gui (KDE) will probably extract it just fine. Below is the command line method of extracting (dot)gz files.
(for bz2, refer to bunzip2 on this site)

This methodology used is so common, it is OFTEN not commented on in an SxS write up, when there are far bigger issues to concentrate on. Essentially

assume you have placed the tarball in /usr/src

cd /usr/src

tar -zxvf <name of tarball>

Hint Use Unix's command extension feature by only typing the beginning of the <name of tarball> then hit TAB

Hint can't remember what the tarball's called?

cd /usr/src
ls -la

The result of the tar command will be the contents of the <name of tarball.tar.gz> will be placed in /usr/src/<name of tarball>

cd /usr/src/<name of tarball>

Hint Use Unix's command extension feature by only typing the beginning of the <name of tarball> then hit TAB

You are now ready to do something with the source. Luke.


"install the tarball"
"./configure make make install"
"compile the tarball"
 " .... in the standard manner"

An SxS is generally pretty good at passing you through these steps. Remember, these steps are SO COMMON they are not particularly specific to THE application you're trying to get running. So........

Understand the foillowing:

Linux comes on so many machine architectures, and so many distros, and so many revisions of code, and so many site specific libraries, lack of libraries, location of libraries that a utility exists to find out who YOU are, and how YOUR system has been put together. It is called autoconf.

Autoconf and it's cousins, essentially take the pain out of installing source code. Source code ain't gonna work if it needs A library, and A specific place to be. Autoconf (and cousins) find out what THIS tarball wants, and where it is on YOUR system.

This wasn't always the case, and some, few tarballs, may not subscirbe to autoconf. They are mercifully becoming rarer.


The following is all you are required to do in a brain dead manner

cd /usr/src/<name of tarball>
(dot)(slash)configure
make
make install

make install is generally done as superman, everything else, including tarball extraction can be done as a mere mortal


The GOTCHA's


If you asked me if the above works, on a Monday, I would say 99% of the time. By Friday, I revise this opinion to 'sometimes'.

The place you need to be is

/usr/src/<name of tarball>/INSTALL and
/usr/src/<name of tarball>/README

these TWO files are generic and mandatory for any tarball source working the autoconf process.

They contain install-specific information other than the above, when necessary (and that is rare).

The SxS write will always contain specific details should the above "in a standard manner" not be the case.


searchSearch Index