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.

When I started I was virtually a noob. I'd farted around with live CDs and installed other distributions (Ubuntu, Mandrake, etc.) on second boxes to experiment, but never got very far. This was essentially my first real experience with Linux (despite all that nonsense about it being to hard for beginners).

In order to easy the burden I relied heavily on Slackbuilds and the pre-built packages on various sites.

However, now that I'm more comfortable with the environment, and building from source, I was wondering if there was any advantage (with stability, or whatever) to using source builds over packages.

From what people have posted in other threads it seems as if this were the case.

Installing software from a package encourages organization and system management. Users know what is installed and from where. Installing from source provides little help with tracking what was done to a system.

Building a package from a build script helps stay organized in that each package gets built according to expected standards.

Many Slackers start the same way as you: downloading prebuilt packages, then learning to build packages from scripts, and then learning to write their own build scripts. Many Slackers mature to a point in which they might still install prebuilt packages but only from people who include the build scripts in the package. The general approach is one of trust. If a person is unwilling to post the build script then can that person be trusted? Most Slackers are reasonably skilled at maintaining their boxes, but I'm guessing most would never think about maintaining their system without building or using packages.

Some people install from source, but that is best reserved for hard core techies and the insane --- and the two groups are not necessarily exclusive!

Well the title is a bit of a misnomer. Slackbuilds are just scripts that ease the compilation and package building process and so are themselves compiling from source.

If you want to talk about pre-compiled packages versus locally compiled then locally compiled will always be superior as they are usually (but not always) tailored for the environment on which they are built. This can, amongst other things, have the benefit of ensuring dependencies are present and altering configuration settings depending on the build environment resulting in better workability.

Slackbuilds do have the benefit, as mentioned,(which is crucial to systema administration), of package management. All locally built software should be packaged so it's components may be easily removed or upgraded - a by product being a record of a system's package maintenance history.

Stand alone none scripted compilation via configure, make, make install may have it's place if the result is built into a package giving it the previously mentioned advantages.

However giving the Make process the opportunity to write to the native filesystem hierarchy with superuser rights without building a package can produce results that are damaging and hard to reverse.

The only advantage is you can compile any package while there only exist Slackbuilds for a small number of packages. I usually try to compile from source first, and if I can't get it to work then I use a Slackbuild (because there's usually a patch that needs to be applied).

If you're going to make your own source build, its not that much more effort to make your own slackbuild script (most are very similar to each other) and it'll come in handy if you ever need to rebuild/reinstall.

If I ever install from source without making a slackbuild for it I put the results under /opt/<program name>/ so its easy to remove again and doesn't pollute my filesystem.

The only pre-build packages I use are Pat's official ones. As Woodsman said, its all about 'trust'.

For me, the disadvantage of install from source have two point:
1, system management issue, as said by may people before;
2,install from source often dump the things into /usr/local, which will mess up the directory. In order to remove the program, you have to preserve the build folder to "make uninstall" in it. Oh, I haven't mention that some buggy source code even doesn't provide "uninstall" target in the makefile...

But to the point 2, I see there is a solution provided by

Quote:

Originally Posted by GazL

If I ever install from source without making a slackbuild for it I put the results under /opt/<program name>/ so its easy to remove again and doesn't pollute my filesystem.

but there comes an other problem - Do you have to append "/opt/<app name>" to PATH every time after you install a program? Could it mess up the env?

You could also use something like paco or another ld preload logger. This eliminates the above problems. You can even remove certain files from the install, as well as dump the package to a tgz that you can then use to make a slackware package if you want.

but there comes an other problem - Do you have to append "/opt/<app name>" to PATH every time after you install a program? Could it mess up the env?

Nope, I just symlink the executables /opt/<program name>/bin/executable (or whatever) into /opt/bin which I created for the purpose and have just /opt/bin added to the path. That way when it comes time to remove, you just have to clear out the broken symlinks.

A nice side effect of this is that you can use this to have multiple versions of something installed at once and switch between them easily.
/opt/program_v1.0/
/opt/program_v2.0/
symlink /opt/bin/program --> to whichever version you want.

This sort of scheme takes some additional effort, but its good for certain situations (testing being a prime example).

Mostly though if it's something that'll be installed long term, I'll stick to building a proper package via a slackbuild and integrating it into slackware the official way.

I am Noob going through the steps described here. I feel using SlackBuilds to compile from source makes the best sense I have ever seen in any Linux environment. I have been playing with Linux on and off again since 1998 or so starting with Redhat. I tried Mandrake then Ubuntu... Ubuntu made me fall in love with Debian. I felt content with Debian but for some reason I decided to check Slackware. (Mostly due to my desire to learn more about Linux) well it was hard for a moment but Slackware won me away. Gentoo tried to steal me from Slackware but lacked the features that make me turn to Slackware.

I feel using SlackBuilds to compile from source makes the best sense I have ever seen in any Linux environment.

I completely agree. Most of the people who criticise Slackware for its 'basic' package management haven't understood the elegance of the slackbuild approach to doing things. I'd take slackbuild over apt-get any day.

I prefer using Slackbuild scripts whenever available, else I compile from source. Technically they are the same, but Slackbuilds make package management easy.

Quote:

Originally Posted by grissiom

2,install from source often dump the things into /usr/local, which will mess up the directory. In order to remove the program, you have to preserve the build folder to "make uninstall" in it. Oh, I haven't mention that some buggy source code even doesn't provide "uninstall" target in the makefile...

Well, you don't have to preserve the build directory. You can simply run 'configure' with the same options you used during installation and then do 'make uninstall'. And you can simply pass --prefix=/usr to configure if you don't want to use /usr/local. I prefer /usr/local though, that way I keep add-on software separate from the system packages and if you keep /usr/local on a separate partition you can continue using the add-on software after upgrades/reinstallations with minimal effort.

Nope, I just symlink the executables /opt/<program name>/bin/executable (or whatever) into /opt/bin which I created for the purpose and have just /opt/bin added to the path. That way when it comes time to remove, you just have to clear out the broken symlinks.

A nice side effect of this is that you can use this to have multiple versions of something installed at once and switch between them easily.
/opt/program_v1.0/
/opt/program_v2.0/
symlink /opt/bin/program --> to whichever version you want.

This sort of scheme takes some additional effort, but its good for certain situations (testing being a prime example).

Mostly though if it's something that'll be installed long term, I'll stick to building a proper package via a slackbuild and integrating it into slackware the official way.

Well, you don't have to preserve the build directory. You can simply run 'configure' with the same options you used during installation and then do 'make uninstall'. And you can simply pass --prefix=/usr to configure if you don't want to use /usr/local. I prefer /usr/local though, that way I keep add-on software separate from the system packages and if you keep /usr/local on a separate partition you can continue using the add-on software after upgrades/reinstallations with minimal effort.

Thanks a lot for your advice. Yes, I put /usr/local on a separate partition and it's very convenient to reinstall the whole system.