LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Packages/Slackbuilds versus Compiling From Source (http://www.linuxquestions.org/questions/slackware-14/packages-slackbuilds-versus-compiling-from-source-678934/)

AlphaSigmaOne 10-25-2008 12:38 AM

Packages/Slackbuilds versus Compiling From Source
 
I've been using Slackware for about six months now.

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.

Woodsman 10-25-2008 01:14 AM

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! ;)

bgeddy 10-25-2008 01:31 AM

Quote:

Packages/Slackbuilds versus Compiling From Source
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.

H_TeXMeX_H 10-25-2008 02:57 AM

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).

GazL 10-25-2008 04:46 AM

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'.

grissiom 10-25-2008 05:32 AM

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 (Post 3321518)
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?

bgeddy 10-25-2008 05:44 AM

Quote:

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?
Well if I do this I find it easier to just create a link in /usr/bin or /usr/local/bin then you don't have to mess with paths.

H_TeXMeX_H 10-25-2008 06:08 AM

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.

GazL 10-25-2008 07:47 AM

Quote:

Originally Posted by grissiom (Post 3321541)
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.

empcrono 10-25-2008 07:49 AM

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.

GazL 10-25-2008 08:05 AM

Quote:

Originally Posted by empcrono (Post 3321606)
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.

Ilgar 10-25-2008 08:43 AM

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 (Post 3321541)
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.

grissiom 10-25-2008 09:14 AM

Quote:

Originally Posted by GazL (Post 3321603)
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.

Thanks a lot ~;) I see your point. I have to admit it is a good way.

grissiom 10-25-2008 09:20 AM

Quote:

Originally Posted by Ilgar (Post 3321643)
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.

AlphaSigmaOne 10-25-2008 02:54 PM

For the record, I haven't tried building my own Slackbuilds yet. (Just DL them from slackbuilds.org.)

Maybe this week I'll read up on them a little and try one for myself.


All times are GMT -5. The time now is 09:17 PM.