I mean like, what does it do differently from just installing something from source? Check to make sure you have the required dependencies before compiling the .tgz package? something else?

Normally a SlackBuild will just Build a package from source.

It's just a script that is written to automate all the steps to create a package.

It can set compiler options and other environmental variables and sometimes even download the source but does not resolve dependencies (unless someone hard codes this in).

More interesting reading to be found here. http://www.slackwiki.org/Writing_A_SlackBuild_Script

Another thing the slackbuild does is: document the build process. Though that's more of a soft benefit.


Strangely enough I was thinking about that very thing the other day and wondering whether to add something along the lines of that to the start of some of my build scripts. Keeping it simple though, like a set of: "test -f /var/log/packages/requiredpackagename* || exit" statements.


I recently had an epiphany and discovered that it's not automated dependency checking, but automated dependency resolution that I object too.

Besides, making it easy to compile a package (it isn't always easy), using a Slackbuild allows you to uninstall the program.

Actually using a Package allows the un-installing =)

Hair-splitter!

Also, the SlackBuild does not *install* the program -it just creates the package. As GazL pointed out, the script provides the most concise documentation of the build, which to me is the *biggest* benefit.

A SlackBuild can also be used to adapt an install to suit the standard Slackware structure. An example of this is the SlackBuild for OpenOffice by rworkman. It actually unpacks the compiled binary rpm package and makes changes to suit Slackware.

Most usually a slackbuild script actually does dependency checking. That is: if the build process performs a "./configure --parameters"

What most of the SlackBuild scripts do:
1) unpack the source
2) run configure
3) make the software
4) "install" it in a safe location which allows for creation of the package
5) add the documentation and other useful resources (like config files) to the package
6) create the package so that it is easy to install, uninstall and upgrade, allowing you to keep the rest of your system clean.

This is, however, NOT what _all_ SlackBuild scripts do; in essence what they do in one line is this:
put together the files into a (compressed) archive in a format that is understood by the package application so that it may be installed, upgraded or un-installed.

Greetz
When building from source, the commonly stated last step of "su make install" does not do it for me because not only do I want to be able to uninstall (and there is no "make uninstall") but I want a record of what is installed and where, That only takes place with packages. Additionally SlackBuilds, for me, fills a hole left by "checkinstall" when it failed to keep up and was dropped from Slackware Extras. For those newer to Slack or who never used it, "su checkinstall" took the place as a direct substitute for "make install" and it could create packages, slacpakcks, debs and/or rpms. It was great while it lasted.

Slackpkg isn't bad but I have yet to learn how to control the configure process the way I want with it. SlackBuilds generally lay it all out and make it easy to set any options you want and I never needed debs or rpms anyway. The dependencies are generally listed from the same place you get the SlackBuild so before you even download it you know what you need. That means you don't have to sit and watch as configure runs for the tenth time stopping on some missing library you must then go fetch and install first. With SlackBuilds you can plan ahead and make compiling all but effortless and go fix a cup of coffee while the build script runs unattended and return ready to go.

1 members found this post helpful.

Does it mean that if I install the VLC player slackbuild, it won't install ALL the codecs on its own? Do I have to download 100 codecs from different websites individually?

From your list of distributions I can make assumptions on the intention of your post but I will simply say that VLC is a rare case where using Alien Bob's prebuilt package (especially the restricted package that contains additional codecs that are not distributable from a US server) is exceptionally advantageous, and is compiled statically so you don't need to chase dependencies. There's a reason a package like VLC should be compiled statically to avoid this dependency mess on ANY distro -- having VLC break every time you upgrade ffmpeg would not be fun, and it has so many dependencies (some of them build-time dependencies only) that I wouldn't compile it from source unless I had to. This, of course, is contrary to my philosophies for almost any other piece of software, but there is a time for pragmatism.

For mplayer though, yes, you'd need to hunt down some dependencies if you're unhappy with the build that ships with Slackware. ffmpeg is another one that can make good use of codecs that may not be included with Slackware. I have a list of codecs from SBo that I generally build before anything else (and I recompile mplayer to take advantage of them). This lets me include support for the codecs that I plan on using without burdening my system with added optional dependencies that will never be used. sbopkg makes preparing queues for these multimedia dependencies relatively painless while still providing you with control over which optional dependencies are to be included.

For those arguing about dependency resolution, in *my* mind the only dependency resolution I would accept would be something akin to Gentoo's portage system with USE flags allowing me to enable/disable optional dependencies at will. Right now I essentially prepare sbopkg queues manually which takes slightly longer than a USE flag-like system but is still reasonable.

1 members found this post helpful.

I am curious to know the assumptions you made about my intentions.

T3slider, thanks for the effort, I had to look up "static compilation" in detail I had previously tried to install VLC tar on Suse, I got soon tired because of the missing codecs..I am planning to shift my external hardisk (used for storing music/movies) to Slackware, You've explained the reasons well.