Slackbuilds.
 

Hi:
I do not understand Slackbuilds.org philosophy. I quote from their home page:
If the target o.s. is, say, slackware 13.1, why not have at hand the binary packages, such as the ones provided by Slackware?

A golden rule is: the best way to install new software is to compile on (or for) the target system. Direct installation of binaries is not as good. OK. But why once the slackbuilds script has done its job not to have the result as a .tgz binary package that I can install in my machine each time I need or want? Well, that is my question for LQ. Thank you for reading.

Aside from anything else I would have thought that keeping a repo up to date for various releases of slack 32bit 13, 32bit 13.1, 64bit 13 etc etc would take a lot of time and effort and also the physical size of all those binary's would be fairly large and frankly its no effort to compile from source it's also more secure as you know exactly what is being installed, if you want to you can always keep the binary's that you make for reinstalling at a future date.

Aha. But the amount of effort would be the same as that taken by the Slackware crew and the size of the binaries exactly the same as that of the packages included in the Slack distros or repository when this existed.

Not realy as the programs on slackbuild are extra to the official slackware binary's many of them are small specialist programs that are used by only a few people so a lot of extra effort for only a few uses and of course the ultimate argument is simple - its their site and they can do whatever they want!

Also, once you've compiled a SlackBuild once, the package exists in /tmp (by default, until you delete it) and if you uninstall it and change your mind, you can just install the package again using Slackware's package manager, and if you use sbopkg (which provides a pkgtool style interface for slackbuilds), it will detect that you already have a binary package on your system and install it in preference to compiling it from source again. Also, I suppose it would be possible to use those packages and migrate them from one PC to another if you wanted, though that sounds to me like more trouble than it's worth. If I'm wrong then please correct me.

Your post is instructive. In fact, the OP was motivated by the need to compile MPlayer. In my machine this is a process which lasts more than an hour. Thanks.

Sure, available packages would come in handy, however I'm thankful for being forced to compile things myself. First of all because I can change all architectures from i486 to i686, and second because the configuration process says whether or not the package will work as intended and if I'm missing something. Furthermore, while I'm not somebody who looks through - let alone changes - any other configuration arguments in the slackbuild, some people prefer to do so.

-A

And also there are sometimes optional dependencies. Having a prebuilt package means that you are using whichever deps were installed by the packager.

Thanks to you both.