SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
yesterday i read a [how to] which help me to configure apache ang php on my computer....i see that the person who write the tutorial didn't use the apache and php from slackware but download the sources of apps and ./configure these alone.i understand why he did it that
BUT i want to ask whats other application its better to install from source with your own configuration?
Personally, I'd say *all* of them...but I'm a Gentoo/FreeBSD fanatic, so I'm biased heh.
Realistically, there are probably only a handful of projects that it makes a major difference if you compile yourself or use a pre-built package (depending on how the package was built, of course). The real bonus to compiling software is that you can configure the software tailored specifically to your system. For "monolithic" distros (Ubuntu, etc...), compiling from source is mostly a waste of time. For the more "hands-on" distros (LFS, Gentoo, etc...), it's pretty much a given that you'll compile it yourself.
Correct me if I'm wrong (I don't claim to know Slackware inside and out), but Slack strikes me as a very versatile "hybrid" distro that balances availability of pre-built packages and the ability to tailor the system to very specific needs (Linux is Linux, but some distros make it easier or more difficult to do certain things...Slackware seems to be a good balance).
Usually, pre-built packages will be OK, depending on where you get them. In Slackware, if you want to rebuild a package that is included by default, you don't necessarily have to start from scratch. The packages (.tgz packages) included in Slackware were built using SlackBuilds, which are just small scripts that you can run to compile the program and create a nice .tgz package that you can install, upgrade and uninstall with ease using installpkg/upgradepkg/removepkg/pkgtool. If you want to change build options from stock Slackware packages, you can simply change the options in the SlackBuild script. There's a good SlackBuild writing guide here: http://slackwiki.org/Writing_A_SlackBuild_Script
The Slackware sources are located on the installation disc(s) (4, 5 and 6 for the CDs, or just on disc 1, obviously, for the DVD) or from your favourite Slackware mirror (in the source directory). For third-party packages not included in Slackware, my favourite resource is slackbuilds.org, which maintains a database of SlackBuild scripts that have been fairly thoroughly tested and known to work. You can, of course, modify build options there too. Pre-built packages can be found at slacky.eu (which also includes the SlackBuild scripts used to make them) and at linuxpackages.net (which does not always include build scripts. linuxpackages.net has some questionable packages that may not have been created on clean systems and may mess things up; however, generally they're OK, and there are some reputable packagers there that create good packages. You just have to find out which contributors are reputable...).
Compiling programs using the standard `./configure; make; make install` is not the best way to do things, because uninstallation or upgrading the package is tricky or impossible without much effort. Uninstallation would depend on the developer(s) of the program creating a good uninstall script (so you can run `make uninstall` in the source directory). However, this is not always the case, and although it is possible to find out which files were installed and remove them, either manually or with some automation, it is more effort than simply creating a .tgz package in the first place, which allows you to use standard Slackware package management tools.
The advantage to using SlackBuilds is that you always maintain a guide as to how you built the program (what options you enabled, any tricks you had to add to get it to compile, etc.) so that if you ever have to rebuild it or build a newer version, it should be much easier.
Note that there is also src2pkg, which is a nice program that attempts to compile the program automatically with little user intervention (although you can pass options to it) and can create a nice package that you can install/uninstall with ease (it also produces a script that shows how the package was built, although it's not technically a SlackBuild script).
I don't think it's necessarily "better" to compile from source, just "different." If you compile from source, you can often do things that you find non-Slackware-specific howtos for. On the other hand, Pat V. is a smart guy, and I trust him to build all the software that he provides.
I'd say that anytime you want a newer version of software than is available from Pat, or if you want software that isn't available from Pat, then you're probably better off compiling yourself (or using a Slackbuild).
The only application that I firmly believe cannot be packaged is MPlayer because of the massive number of compile-time options that determine the dependencies of a particular build of MPlayer. TiMidity is a close second for the same reason, but nearly all the libraries that TiMidity could possibly need are already in the stock install, so it's not so bad.
In general, you should probably build your own package if the available ones don't have the features you want. For instance, if you are building WINE, you may want to have OpenGL support enabled, so you might want to build this yourself. For a media program, you may want to use alsa for sound output and not libao. You may want to build a fluxbox package with imlib2 support (so you can have icons in the root menu) as well. All of these are examples of why you would want to build your own package. And yes, you can build for your processor, but that is probably the least useful thing compared to the other examples I mentioned.
In general, when you build your own package, you know that it will only need the libraries that you have on your machine (otherwise it probably won't build). Somebody else's may not work on your current setup.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.